nextcloud writes data to new nfs mounted data mount without issue
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:
[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
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.
[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 |
+---------+-------+--------------+
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
Browser: chrome/firefox
Operating system: Windows/Linux
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.
[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...')
# 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)
$ 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.
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]