After Desaster recovery i get Data directory is not writable

fsoelch · December 30, 2020, 3:53pm

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 …

Regards
Florian

alfredb · December 30, 2020, 4:26pm

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?

fsoelch · December 30, 2020, 8:23pm

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

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

Expected behaviour

login and be happy

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

Database:
MySQL

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
http://download.owncloud.org/download/repositories/production/Ubuntu_20.04/

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

The content of config/config.php:

<?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' => '10.5.0.10',
  '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:

Enabled:

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
Disabled:
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
no

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

Client configuration

Browser:
Chrome

Operating system:
Windows

Logs

Web server error log

nothing relatred to owncloud

ownCloud log (data/owncloud.log)

remains empty with final path

Browser log

not a browser issue

alfredb · December 30, 2020, 10:01pm

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

fsoelch · December 30, 2020, 10:29pm

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 …

Regards
Florian

alfredb · December 31, 2020, 7:30am

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.

tom42 · December 31, 2020, 9:40am

Hey,

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

fsoelch · December 31, 2020, 5:00pm

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

<?php
$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
/var/www/owncloud/lib/private/legacy/util.php
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
Florian

alfredb · January 1, 2021, 9:09am

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

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

fsoelch · January 1, 2021, 9:13pm

Hi alfredb,

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

Regards
Florian