Occ not running ErrorMsg: App directory not found... (Cron not working, Apps not shown)

Problem description

I have three observation that something with the installation seems not to be correct.

  1. Cron does not run and a error message is in the admin page
  2. I do not see any addIns when clicking in the top left corner in the owncloud web page.
  3. occ terminates with an error message

I describe the observation with 3 since there is actually an error message.

Remark: thanks in advance for reading and helping.

Steps to reproduce

I wanted to run the occ command and did the following:

  1. I have just newly installed owncloud. The file exchange and interaction seems to work
  2. Log in with ssh to server
  3. changed to directory where the occ command is (i.e. /subdomains/myDomainDirectory.mySubdomain/)
  4. run ‘/opt/php73/bin/php occ’

(Remark: for some reason I cannot run with sudo. I guess my hoster does not allow it).

Expected behaviour

I was expecting the get the help text of occ.

Actual behaviour

The occ command seemed to execute but with some internal error resulting in the message.
(-> occ is running but terminating with error message (not crashing).)

App directory "/home/httpd/vhosts/myServer.com/subdomains/myDomainDirectory.mySubdomain/apps" not found! Please put the ownCloud apps folder in the ownCloud folder or the folder above. You can also configure the location in the config.php file.

Additional info

I tried to change the path in the config.php for the apps. But whatever I do, occ crashes more seriousely (with >30 lines of crash dump).

Goal of this question

Answer that results in the following:

  • occ command runs
  • cron works requlareyl
  • apps are shown

What I have done

Searched web for this error message -> no luck (unbelievable)
Searched web for cron not working -> nothing made sense to me
Searched web for not showing apps-> only found issues about specific apps

Server configuration

Operating system: don’t know

Web server:: managed with PLESK, I guess it is Apache

Database:: mySQL

PHP version:: 7.3.14

ownCloud version:, Community edition

Updated from an older ownCloud or fresh install: no, newly installed from

Where did you install ownCloud from: owncloud-10.3.2.zip from owncloud.org. Extracted to folder and run setup with first-time-login.

Signing status (ownCloud 9.0 and above):

Login as admin user into your ownCloud and access 
paste the results into https://gist.github.com/ and puth the link here.

The content of config/config.php:
no change made, i.e. original config.php

List of activated apps:
standard just after installing

Are you using external storage, if yes which one: no

Are you using encryption: no

**Are you using an external user-backend, if yes which one:**no

Can you run an ls -laZ in that directory and paste the output here?

Hi eneubaur

thanks for reading my issue. Here is the dump. According to
my hoster, dummy1024 is the user and psacln the group used
to send data to web clients.

Maybe I did not perform correctly the post-installation procedure for making occ runing.
But whatever I do, I have no success.

Below, some folders (apps, config,) are set to 777 with chmod. Not even that way, it is working.
Since this might not be secure, I’ll wipe soon all and restart from scratch (which I’ve already done
several times).

Remark: the server is running CentOS 7.

-rw-r--r-- dummy1024 psacln  ?                                .htaccess
-rw-r--r-- dummy1024 psacln  ?                                .user.ini
-rw-r--r-- dummy1024 psacln  ?                                AUTHORS
-rw-r--r-- dummy1024 psacln  ?                                CHANGELOG.md
-rw-r--r-- dummy1024 psacln  ?                                COPYING
-rw-r--r-- dummy1024 psacln  ?                                README.md
-rw-r--r-- dummy1024 psacln  ?                                __.htaccess_original
drwxrwxrwx dummy1024 psacln  ?                                apps
drwxr-xr-x dummy1024 psacln  ?                                apps-external
drwxrwxrwx dummy1024 psacln  ?                                config
-rw-r--r-- dummy1024 psacln  ?                                console.php
drwxr-xr-x dummy1024 psacln  ?                                core
-rw-r--r-- dummy1024 psacln  ?                                cron.php
drwxr-xr-x dummy1024 psacln  ?                                data
-rw-r--r-- dummy1024 psacln  ?                                db_structure.xml
-rw-r--r-- dummy1024 psacln  ?                                index.html
-rw-r--r-- dummy1024 psacln  ?                                index.php
drwxr-xr-x dummy1024 psacln  ?                                lib
-rwxr-xr-x dummy1024 psacln  ?                                occ
drwxr-xr-x dummy1024 psacln  ?                                ocm-provider
drwxr-xr-x dummy1024 psacln  ?                                ocs
drwxr-xr-x dummy1024 psacln  ?                                ocs-provider
-rw-r--r-- dummy1024 psacln  ?                                public.php
-rw-r--r-- dummy1024 psacln  ?                                remote.php
drwxr-xr-x dummy1024 psacln  ?                                resources
-rw-r--r-- dummy1024 psacln  ?                                robots.txt
drwxr-xr-x dummy1024 psacln  ?                                settings
-rw-r--r-- dummy1024 psacln  ?                                status.php
drwxr-xr-x dummy1024 psacln  ?                                updater
-rw-r--r-- dummy1024 psacln  ?                                version.php

When you’re logging in via SSH, are you either using the psacln or the dummy1024 user?

In order to be able to run occ commands you have to login as the web server user.

I am logging in as dummy1024. This is the only login I have. Isn’t the psacln a user group.

Question: do you think the directory rights are ok?

I don’t see anything inherently wrong with it, just a little suprised that this is a CentOS system that doesn’t have SELinux context labels on the files. But I don’t know if this is due to Plesk and you’re saying everything else seems to be working, so I’m not too concerned.

Generally though it’s going to be very hard to reproduce anything without a Plesk server.

Can you paste the full command you’re entering with the exact CLI output?

Can you try running your command using full paths, i.e:

/opt/php73/bin/php -f /home/httpd/vhosts/myServer.com/subdomains/myDomainDirectory.mySubdomain/occ

@ eneubauer: thanks a lot for your reply. Since I also have a job, I only can react outside business hours. Still, I value your help a lot.

Overview: still not working, but I learn a lot and getting a little closer. I think.

New observation:

For some reason (after about 3 new installations of owncloud on different subdomains), I can use the Marketplace and install apps on the web page. OCC still does not work.

Running different commands:

Your proposal:

/opt/php73/bin/php -f /home/httpd/vhosts/myServer.com/subdomains/myDomainDirectory.mySubdomain/occ

Result: it did not even find the the command. Talking back with the server support, this seems to make sense since I have only ‘chrooted’ access, i.e. the user is locked in the home directory which is equivalent to /home/httpd/vhosts/myServer.com

So I tried to run the command from the chroot directory:

/opt/php73/bin/php -f/subdomains/myDomainDirectory.mySubdomain/occ

Result: same error message as originally.

Change in config.php:

So I changed the directories for the apps in the config.php, i.e. the struct ‘apps_paths’ :



with deleting the trailing stuff to:


Result: On the web pages which was originally running, I’m getting now the exact same was with the occ command. When I am running the occ command now, it crashes terribly, i.e. with an unhandled exeption when trying to use some SQL statements.

Conclusion: running the web pages seems to work with the standard setup and it finds the apps with the complete path setting. It seems that the occ command does not uses the same settings / settings file.

Full command and error message:

Full command:

/opt/php73/bin/php occ

in the folder where the occ comman is

Full error message:

App directory "/home/httpd/vhosts/myServer.com/subdomains/myDomainDirectory.mySubdomain/apps" not found! Please put the ownCloud apps folder in the ownCloud folder or the folder above. You can also configure the location in the config.php file.

As mentioned above, when changing config.php, the exact same message pops up.

Unqualified quess:

Maybe the occ command gets somewhere in trouble with chrooted systems. Maybe it requires at some place the full path and not only starting with the home path. But how I would solve this…
Question: is there a way on the server to dump the calling order / stack until the error message pops up? This is more a php developer question…

1 Like

Update: I started debugging the occ command on the server (with lots of echo commands).

The error message is thrown in the function lib/base.php (occ -> console.php -> lib/base.php).

I can either choose the long path option and the error is thrown since the php function \is_dir() declars it not as a path. If I use the short version, it passes this part but it crashes at another place.
If I just disable throwing the error, it crashes also.

The new error messag is as follows:

An unhandled exception has been thrown:
Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2002] No such file or directory in /subdomains/myDomainDirectory.mySubdomain/lib/private/DB/Connection.php:62
Stack trace:
0 /subdomains/myDomainDirectory.mySubdomain/lib/composer/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
etc (full stack trace)

Additional info: I checked within the php file for the user that is running the script. Both time, with occ on ssh and on the running web page, it is the same user dummy1024.

OK, so I think you won’t be able to get occ running in an SSH session.

While reading your previous post I was also thinking you should try more relative paths. They should still be correct in the chrooted environment.

This would mean that the connection string inside your config.php is not correct. As you’re saying that the ownCloud WebUI works for you, I would think that this is again due to the chrooted environment.

I have one more idea though:
Can you try running the occ command in a cron job? Often these shared hosting providers offer a way to configure cron jobs, that in theory should run commands in the correct environment.

Hello eneubaur
thanks for your answer. Unfortunately I have to agree with you on occ not running in SSH session
without changes in the chrooted concept of my provider.

I thought I could just work with two config.php, one for occ and one for the web page. But also this does not work. So I checked the mysql database. And there are plenty of references to the full path which are all not valid running in the chrooted environment.

About your idea of using a cron job doing it. Maybe this is a good idea. But first I have to figure out in what environment cron jobs are running. Since the cron setting inside owncloud do not work, I guess there are similar problems. I also found other discussions on the web with owncloud cron job not working in chrooted environments.

Maybe I just use a hack and run occ commands (via console.php) with a temporary php script accessible online.
And I’ll try to find out how to issue a bug-report / feature-request from the owncloud developers. I guess, Nextcloud has the same issue.

If I find out more, I’ll let you know on this post. For them moment, thanks a lot for your kind help.


if the occ command doesn’t work within a chrooted environment maybe you can make the ownCloud team aware of this at https://github.com/owncloud/core/issues ?