Server: Php v7 filesystem check bug with nfs v3 mount from synology

Created on 9 Nov 2017  路  20Comments  路  Source: nextcloud/server

Steps to reproduce

  1. Arch linux LAMP stack with nextcloud installed using (https://wiki.archlinux.org/index.php/Nextcloud#Installation)
  2. set fstab to mount synology nfs v3 mount on to data directory (migrating the default data in the process)
  3. Check/fix permissions using script located at https://docs.nextcloud.com/server/9/admin_manual/installation/installation_wizard.html
  4. restart httpd service

Expected behaviour

nextcloud writes data to new nfs mounted data mount without issue

Actual behaviour

nextcloud error "Your data directory is not writable"

[root@lin-virt02 nextcloud]# sudo -u http php occ files:scan admin
Your data directory is not writable
Permissions can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/12/go.php?to=admin-dir_permissions.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /usr/share/webapps/nextcloud/lib/private/Console/Application.php:145
Stack trace:

0 /usr/share/webapps/nextcloud/console.php(99): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))

1 /usr/share/webapps/nextcloud/occ(11): require_once('/usr/share/weba...')

Troubleshooting

[root@lin-virt02 nextcloud]# sudo -u http ls -alh data
total 436K
drwxrwxrwx 1 http http 188 Nov 9 04:00 .
drwxr-x--- 16 http http 4.0K Nov 9 03:54 ..
drwxr-x--- 1 http http 76 Sep 30 02:03 admin
drwxr-x--- 1 http http 146 Sep 27 19:19 appdata_ocb0vuuo4fin
drwxr-x--- 1 http http 26 Oct 25 19:14 files_external
-rw-r--r-- 1 http http 324 Sep 27 17:43 .htaccess
-rw-r----- 1 http http 0 Sep 27 17:43 index.html
-rw-r----- 1 http http 428K Nov 7 15:23 nextcloud.log
-rw-r----- 1 http http 0 Sep 27 17:43 .ocdata

[root@lin-virt02 nextcloud]# sudo -u http touch data/test

[root@lin-virt02 nextcloud]# sudo -u http ls -alh data
total 436K
drwxrwxrwx 1 http http 196 Nov 9 04:00 .
drwxr-x--- 16 http http 4.0K Nov 9 03:54 ..
drwxr-x--- 1 http http 76 Sep 30 02:03 admin
drwxr-x--- 1 http http 146 Sep 27 19:19 appdata_ocb0vuuo4fin
drwxr-x--- 1 http http 26 Oct 25 19:14 files_external
-rw-r--r-- 1 http http 324 Sep 27 17:43 .htaccess
-rw-r----- 1 http http 0 Sep 27 17:43 index.html
-rw-r----- 1 http http 428K Nov 7 15:23 nextcloud.log
-rw-r----- 1 http http 0 Sep 27 17:43 .ocdata
-rw-r--r-- 1 http http 0 Nov 9 04:00 test

FIX

Comment out:

/usr/share/webapps/nextcloud/lib/private/legacy/util.php

                   } else if (!is_writable($CONFIG_DATADIRECTORY) or !is_readable($CONFIG_DATADIRECTORY)) {
                           //common hint for all file permissions error messages
                           $permissionsHint = $l->t('Permissions can usually be fixed by giving the webserver write access to the root directory. See %s.',
                                   [$urlGenerator->linkToDocs('admin-dir_permissions')]);
                           $errors[] = [
                                   'error' => 'Your data directory is not writable',
                                   'hint' => $permissionsHint
                           ];

AND

/usr/share/webapps/nextcloud/lib/private/Console/Application.php

           if ($input->getFirstArgument() !== 'check') {
                   $errors = \OC_Util::checkServer(\OC::$server->getSystemConfig());
                   if (!empty($errors)) {
                           foreach ($errors as $error) {
                                   $output->writeln((string)$error['error']);
                                   $output->writeln((string)$error['hint']);
                                   $output->writeln('');
                           }
                           throw new \Exception("Environment not properly prepared.");
                   }
           }

Then reboot httpd service. After doing this uploads and downloads are successful and no errors are presented.

Test

[root@lin-virt02 nextcloud]# sudo -u http php occ files:scan admin
Starting scan for user 1 out of 1 (admin)

+---------+-------+--------------+
| Folders | Files | Elapsed time |
+---------+-------+--------------+
| 12 | 19 | 00:00:00 |
+---------+-------+--------------+

Server configuration

Operating system: Arch linux

Web server: Apache

Database: Mariadb

PHP version: 7

Nextcloud version (see Nextcloud admin page): Nextcloud 12.0.3

Updated from an older Nextcloud/ownCloud or fresh install: Installed 6 months ago and kept up to date via package manager.

Where did you install Nextcloud from: Arch repo

Client configuration

Browser: chrome/firefox

Operating system: Windows/Linux

bug filesystem

Most helpful comment

I would recommend we get rid of is_writable() because this is not a reliable check.

Best is maybe to actually try writing a file?

[edit: ran in to this in #11145]

All 20 comments

Did you verify that you can upload via webinterface? This would mean that there is a bug in the is_writable() function of php...
The documentation says that this function caches the result: http://php.net/manual/en/function.is-writable.php

Yes, I'm now able to login and upload/download/delete via the web interface.

Still encountering the same issue on Version 13.0.0. The fix still works but gives code integrity check warnings.

PHP
Version: 7.2.2
Memory Limit: 512 MB
Max Execution Time: 3600
Upload max size: 511 MB

Database
Type: mysql
Version: 10.1.31
Size: 2.4 MB

I'm also encountering this issue, when running within a docker container on kubernetes. The data directory is also from a synology nas unit.

Error

[owncloud][PHP][3] Narrowing occurred during type inference. Please file a bug report on bugs.php.net at /nextcloud/lib/composer/composer/ClassLoader.php#444
Cannot write into "apps" directory
This can usually be fixed by giving the webserver write access to the apps directory or disabling the appstore in the config file. See https://docs.nextcloud.com/server/12/go.php?to=admin-dir_permissions

Your data directory is not writable
Permissions can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/12/go.php?to=admin-dir_permissions.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /nextcloud/lib/private/Console/Application.php:145
Stack trace:
#0 /nextcloud/console.php(99): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#1 /nextcloud/occ(11): require_once('/nextcloud/cons...')
#2 {main}[setup] Trying ownCloud upgrade again to work around ownCloud upgrade bug...
Cannot load Zend OPcache - it was already loaded
[owncloud][PHP][3] Narrowing occurred during type inference. Please file a bug report on bugs.php.net at /nextcloud/lib/composer/composer/ClassLoader.php#444
Cannot write into "apps" directory
This can usually be fixed by giving the webserver write access to the apps directory or disabling the appstore in the config file. See https://docs.nextcloud.com/server/12/go.php?to=admin-dir_permissions

Your data directory is not writable
Permissions can usually be fixed by giving the webserver write access to the root directory. See https://docs.nextcloud.com/server/12/go.php?to=admin-dir_permissions.

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /nextcloud/lib/private/Console/Application.php:145
Stack trace:
#0 /nextcloud/console.php(99): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#1 /nextcloud/occ(11): require_once('/nextcloud/cons...')

NFS and Mount settings

# on the NAS
$ cat /etc/exports | grep nextcloud
/volume4/nextcloud      10.10.10.100(rw,sync,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)


In container
$ mount | grep nextcloud
10.10.10.8:/volume4/nextcloud on /data type nfs4 (rw,relatime,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.10.10.100,local_lock=none,addr=10.10.10.8)

Dir info

$ ls -lan /data
drwxr-xr-x    1 9000     9000           196 May  2 14:45 .
drwxr-xr-x    1 0        0             4096 May  7 16:12 ..

Nextcloud is running as uid/gid 9000/9000.

I will note that it was previously working when I was running the nfs server on CoreOS instead of the synology nas unit.

Can also verify behaviour on 13.0.3 and newest 13.0.4 release.

Setup:
Ubuntu 18.04
Nginx 1.14
MariaDB 10.1.29
PHP 7.2

Data folder symlinked to NFS mount on Synology RS816:

root@files:/usr/share/nginx/nextcloud# ll
total 120
drwxr-xr-x 13 www-data www-data  4096 Jun 18 15:07 ./
drwxr-xr-x  5 root     root      4096 Jun 13 15:23 ../
...
lrwxrwxrwx  1 root     root         9 Jun 18 14:19 data -> /mnt/data/
...

root@files:/usr/share/nginx/nextcloud# df -h
Filesystem                     Size  Used Avail Use% Mounted on
...
<xx.xx.xx.xx>:/volume1/nextcloud   11T  3.1T  7.8T  29% /mnt/data

Commenting out checks as noted by @Xarin continues to function as a workaround, but has to be re-applied after every update; not ideal. Filesystem permissions are all right, www-data user writing / deleting via shell works just fine, as does uploading / deleting via the Nextcloud web UI after commenting out these checks.

I would recommend we get rid of is_writable() because this is not a reliable check.

Best is maybe to actually try writing a file?

[edit: ran in to this in #11145]

Any update on this issue?

The issue seems to be unaddressed even in v14.0.4.

The issue only started after an upgrade from ubuntu 16.04 -> 18.04. The www-data user can write to the directory and appying the "fix" allows the program to function properely. Clearly, the php is_writable() function is the issue.... I've even got the uid of www-data and the owner on the NAS to be the same.

Can we get a different check... even for just nfs?

Just verified I'm running into this issue on v15. Very annoying. Can't use NFS mounts because of this.

This post has a workaround that involves modifying the code itself.

Is there any update on this? Also running this when mounting an NFS v4.1 share onto a Ubuntu 18.04 host, with that directory mapped into a Nextcloud docker volume's data/ dir.

Have double checked by exec'ing into the container and writing a file into the directory, and it is indeed writeable.

I'm having this issue, specifically with an EFS mount on AWS. Everything seems to work OK. Can this error safely be ignored?

Currently the installation fails because of lib/Setup.php still has !is_writable($dataDir))

The official docker image is being used.
Even if I comment out the lines inside Setup.php and get the installation step passed getAppDataFolder() in lib/private/Files/AppData/AppData.php throws NotPermittedException. I am able to create dirs by www-data inside the docker container:

user@nextcloud:~/nextcloud$ docker exec -it --user www-data nextcloud sh
$ mkdir data/d_speranskiy/files/test
$ ls data/d_speranskiy/files
test
$ rm -r data/d_speranskiy/files/test
rm: remove write-protected directory 'data/d_speranskiy/files/test'? y
$ 
user@nextcloud:~/nextcloud$ docker exec -it --user www-data nextcloud sh
$ php occ
An unhandled exception has been thrown:
RuntimeException: Could not get appdata folder for text in /var/www/html/lib/private/Files/AppData/AppData.php:119
Stack trace:
#0 /var/www/html/lib/private/Files/AppData/AppData.php(158): OC\Files\AppData\AppData->getAppDataFolder()
#1 /var/www/html/apps/text/lib/Service/DocumentService.php(114): OC\Files\AppData\AppData->newFolder('documents')
#2 [internal function]: OCA\Text\Service\DocumentService->__construct(Object(OCA\Text\Db\DocumentMapper), Object(OCA\Text\Db\StepMapper), Object(OC\Files\AppData\AppData), NULL, Object(OC\Files\Node\LazyRoot), Object(OC\Memcache\Factory), Object(OC\AppFramework\Logger), Object(OC\Share20\Manager), Object(OC\AppFramework\Http\Request), Object(OC\DirectEditing\Manager), Object(OC\Lock\DBLockingProvider))
#3 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(83): ReflectionClass->newInstanceArgs(Array)
#4 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(100): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
#5 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(115): OC\AppFramework\Utility\SimpleContainer->resolve('OCA\\Text\\Servic...')
#6 /var/www/html/lib/private/AppFramework/DependencyInjection/DIContainer.php(415): OC\AppFramework\Utility\SimpleContainer->query('OCA\\Text\\Servic...')
#7 /var/www/html/lib/private/AppFramework/DependencyInjection/DIContainer.php(386): OC\AppFramework\DependencyInjection\DIContainer->queryNoFallback('OCA\\Text\\Servic...')
#8 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(70): OC\AppFramework\DependencyInjection\DIContainer->query('OCA\\Text\\Servic...', true)
#9 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(100): OC\AppFramework\Utility\SimpleContainer->buildClass(Object(ReflectionClass))
#10 /var/www/html/lib/private/AppFramework/Utility/SimpleContainer.php(115): OC\AppFramework\Utility\SimpleContainer->resolve('OCA\\Text\\Comman...')
#11 /var/www/html/lib/private/AppFramework/DependencyInjection/DIContainer.php(415): OC\AppFramework\Utility\SimpleContainer->query('OCA\\Text\\Comman...')
#12 /var/www/html/lib/private/ServerContainer.php(134): OC\AppFramework\DependencyInjection\DIContainer->queryNoFallback('OCA\\Text\\Comman...')
#13 /var/www/html/lib/private/Console/Application.php(220): OC\ServerContainer->query('OCA\\Text\\Comman...')
#14 /var/www/html/lib/private/Console/Application.php(135): OC\Console\Application->loadCommandsFromInfoXml(Array)
#15 /var/www/html/console.php(98): OC\Console\Application->loadCommands(Object(Symfony\Component\Console\Input\ArgvInput), Object(Symfony\Component\Console\Output\ConsoleOutput))
#16 /var/www/html/occ(11): require_once('/var/www/html/c...')

@sprnza you should open another issue. I'm running version 18 on a NFS mount with no problems.

But please ask the community for advice first.

@rcdailey okay. Just to clarify: are you able to create new users? It seems to me that my issue causes the initial setup I try to perform.

@sprnza Again I encourage you to follow @kesselb's advice and ask in the community. He provided a link for you. I don't think we should ping people with notifications on this thread unless the original issue has regressed.

Just recently rebuilt my nextcloud server on docker, and it does look like this is still an issue.

https://github.com/nextcloud/server/blob/master/lib/private/Setup.php - Line 312
if ((!is_dir($dataDir) && !mkdir($dataDir)) || !is_writable($dataDir))

which still fails when using a synology mount, commenting out 312-314 fixes the issue.

// validate the data directory
//  if ((!is_dir($dataDir) && !mkdir($dataDir)) || !is_writable($dataDir)) {
//    $error[] = $l->t("Can't create or write into the data directory %s", array($dataDir));
//  }

Problem still exists. I am using docker fpm and tried to move config and custom_apps directory to nfs. Afterwards nextcloud 18 rejected to start caused by is_writable checks in lib/private/legacy/util.php
After I had disabled the "Check if there is a writable install folder." and "Check if config folder is writable." NC is working again.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

arno01 picture arno01  路  3Comments

rullzer picture rullzer  路  3Comments

georgehrke picture georgehrke  路  3Comments

juliushaertl picture juliushaertl  路  3Comments

williambargent picture williambargent  路  3Comments