After Desaster recovery i get Data directory is not writable

Hi all,

after a desaster recovery of owncloud
(new Ubuntu 20.04 install, DB reimport and mount of data files on the same location) i get
‘Your Data directory is not writable by ownCloud’
no matter what i tried (setting access rigths manually of via script …) error remains the same.
However, if i change
‘datadirectory’ => ‘’,
in /config.php the login apears. If i than chnage the datadirectory back to my mounted path, i can still login and work perfektly (upload donwload of files worked perfektly)
Once i logout i again get ‘Your Data directory is not writable by ownCloud’

i would be glad of any hint how to get any further on this to restore my server back to normal …


Moving the pointer to the datadir elsewhere cannot solve anything.
You must set ownership and access rights according the docs.

BTW, would you mind fill out the template?

1 Like

Hi alfredb,

thanks a lot for your super quick reply.
Absolutely this can’t solve anything. But it proves that owncloud (or apache as www-data) can read & write from the actual target directory once th initial validation had been passed.

sorry for not filling the template. Here we go:

Steps to reproduce

  1. fresh install owncloud
  2. point datadirectory to /mnt/own_cloud_data
  3. open webpage reports ‘Your Data directory is not writable by ownCloud’

Expected behaviour

login and be happy :slight_smile:

Actual behaviour

startscrren (at index.php/login) shows:
Your Data directory is not writable by ownCloud

Berechtigungen können normalerweise repariert werden, indem dem Webserver Schreibzugriff auf das Wurzelverzeichnis gegeben wird.

rigths are set to 777 including /mnt/own_cloud_data
sudo -u www-data ls -la /mnt/own_cloud_data/ list the files

group looks strange, this seems to be from the nfs share but is as was before
sudo -u www-data vi /mnt/own_cloud_data/owncloud.log

rigths had also been set using the script proivided

Server configuration

Operating system:
Ubuntu 20.04.1

Web server:
apache 2


PHP version:
php 7.4.3

ownCloud version: (see ownCloud admin page)

Updated from an older ownCloud or fresh install:
fresh install, but desaster recovery by reimporting DB tables after installation and mounting data directory

Where did you install ownCloud from:
via apt from

Signing status (ownCloud 9.0 and above):
can’t login :frowning:

The content of config/config.php:

$CONFIG = array (
  'updatechecker' => false,
  'instanceid' => '<my id>',
  'passwordsalt' => '<my pwdsalt>',
  'secret' => '<my secret>',
  'trusted_domains' =>
  array (
    0 => 'localhost',
  'datadirectory' => '/mnt/own_cloud_data',
  'overwrite.cli.url' => 'https://<my domain>',
  'dbtype' => 'mysql',
  'version' => '',
  'dbname' => 'owncloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'owncloud',
  'dbpassword' => '<some pwd>',
  'logtimezone' => 'UTC',
  'apps_paths' =>
  array (
    0 =>
    array (
      'path' => '/var/www/owncloud/apps',
      'url' => '/apps',
      'writable' => false,
    1 =>
    array (
      'path' => '/var/www/owncloud/apps-external',
      'url' => '/apps-external',
      'writable' => true,
  'installed' => true,
  'theme' => '',
  'loglevel' => 0,
  'maintenance' => false,
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'mail_domain' => '<mydomain>',
  'mail_from_address' => 'admin',
  'mail_smtpmode' => 'smtp',
  'mail_smtphost' => 'localhost',
  'mail_smtpport' => '25',

List of activated apps:


  • activity: 2.6.0
  • calendar: 1.6.4
  • comments: 0.3.0
  • configreport: 0.2.0
  • contacts: 1.5.5
  • dav: 0.6.0
  • drawio: 0.0.9
  • encryption: 1.4.0
  • extract: 1.2.4
  • federatedfilesharing: 0.5.0
  • files: 1.5.2
  • files_clipboard: 1.0.3
  • files_external: 0.7.1
  • files_mediaviewer: 1.0.3
  • files_sharing: 0.13.0
  • files_texteditor: 2.3.0
  • files_textviewer: 1.0.3
  • files_trashbin: 0.9.1
  • files_versions: 1.3.0
  • firstrunwizard: 1.2.0
  • gallery: 16.1.1
  • market: 0.6.0
  • notes: 2.0.6
  • tasks: 0.9.7
  • updatenotification: 0.2.1
  • admin_audit
  • announcementcenter
  • customgroups
  • enterprise_key
  • external
  • federation
  • files_antivirus
  • files_classifier
  • files_external_dropbox
  • files_external_ftp
  • files_ldap_home
  • files_pdfviewer
  • firewall
  • guests
  • notifications
  • oauth2
  • password_policy
  • provisioning_api
  • ransomware_protection
  • sharepoint
  • systemtags
  • systemtags_management
  • templateeditor
  • theme-enterprise
  • twofactor_totp
  • user_external
  • user_shibboleth
  • wopi
  • workflow

Are you using external storage, if yes which one: local/smb/sftp/…
only local mounted nfs storage:
on /mnt/own_cloud_data type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,hard,proto=tcp,timeo=14,retrans=2,sec=sys,clientaddr=,local_lock=none,addr=)

Are you using encryption: yes/no

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/…

Client configuration


Operating system:


Web server error log

nothing relatred to owncloud

ownCloud log (data/owncloud.log)

remains empty with final path

Browser log

not a browser issue

Everything is executable? Nice.
I would reduce the x to to directories only.

This only states, that the content can be read.
How about something like

sudo -u www-data ls -la > /mnt/own_cloud_data/foobar4ever

Hi alfredb,

Yes, just to ensure this is not a issue. Will change back once I have it working again.

Creates a file like
sudo -u www-data touch /mnt/own_cloud_data/test.txt
Creates a editable file as well.

And the strange thing: once i passed the check with using the default dir and switched back to the mounted one, I can use ownCloud perfectly fine with reading old files as well as creating and reading new once on that new mounted fliesystem …


Yes, this is really strange.

I’m out of idea, except:

I cannot say anything helpful regarding nfs4, but AFAIR my last use
of mounted volumes, I had to mount them with uid/gid of user www-data.


i think this could have something to do with the hard-coded path values to the datadir in the database:

1 Like

Hi all,
this is a strange behaviour related to php … i created a little test script to tear donw the issue:

$filename = '/mnt/own_cloud_data/test.txt';
if (is_writable($filename)) {
    echo 'YES! Die Datei kann geschrieben werden ' . $filename . "\r\n";
} else {
    echo 'NO! Die Datei kann nicht geschrieben werden ' . $filename . "\r\n";

$filename = '/mnt/own_cloud_data';
if (is_writable($filename)) {
    echo 'YES! Das Verzeichnis kann geschrieben werden ' . $filename . "\r\n";
} else {
    echo 'NO! Das Verzeichnis kann nicht geschrieben werden ' . $filename . "\r\n";

and guess what, the output is:

YES! Die Datei kann geschrieben werden /mnt/own_cloud_data/test.txt
NO! Das Verzeichnis kann nicht geschrieben werden /mnt/own_cloud_data

so i have a writebale file within the directory, but get toled by php that the directory is not writebale, also it is set to 777.

if i adopt
line 766 to
} elseif (!\is_writable($CONFIG_DATADIRECTORY**.’/.ocdata’**) or !\is_readable($CONFIG_DATADIRECTORY)) {
all (except the scurity check of course) seems to be working fine!

any ideas on that bahviour?

many thanks

Adding a trailing slash to the data directory makes any difference?

$filename = '/mnt/own_cloud_data/';
is_writable($filename) {
1 Like

Hi alfredb,

Thanks, good idea!
One of the firth think in my mind as well, unfortunately with the same result :frowning: