Cannot create or write into data directory (NFS mounted)

[52Buickman]

I’m perplexed over this configuration error where NextCloud’s initial configuration cannot write to the defined data directory. I’ve checked ownership and permissions on the directory to be correctly assigned to the “apache” user. I can even touch/create a file on the mount from the CLI with no issue.

What is NC doing to validate the ability to create/write to the directory?

[root@nc02 ~]# ps -ef | grep httpd
root        5119       1  0 21:53 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      5121    5119  0 21:53 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      5122    5119  0 21:53 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      5123    5119  0 21:53 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache      5124    5119  0 21:53 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
root        5341    4969  0 21:59 pts/0    00:00:00 grep --color=auto httpd
[root@nc02 ~]# ls -ld /mnt/NextCloud/
drwxrwsr-x. 5 apache apache 5 Nov  9 21:35 /mnt/NextCloud/
[root@nc02 ~]# ls -ld /mnt/NextCloud/Data
drwxrwsr-x. 2 apache apache 3 Nov  9 21:44 /mnt/NextCloud/Data
[root@nc02 ~]# mount | grep Next
nas1.local.dom:/mnt/vol1/nfs1/export/home/common/NextCloud on /mnt/NextCloud type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.11.211,mountvers=3,mountport=705,mountproto=udp,local_lock=none,addr=192.168.11.211)
[root@nc02 ~]# sudo -u apache touch /mnt/NextCloud/Data/junk
[root@nc02 ~]# ls -l /mnt/NextCloud/Data/
total 1
-rw-r--r--. 1 apache apache 0 Nov  9 22:01 junk

Running on Rocky 9.2, Apache, PHP 8.2, MariaDB 10.5.22

[52Buickman]

I ran into this https://stackoverflow.com/questions/50707811/php-is-writable-false-for-nfs-folder-although-files-can-be-written that discusses a PHP 7.x bug for wrapper is_writable() returning a false on NFS filesystems.

The solution was to just comment out is_writable() routines in lib/legacy/OC_Util.php and lib/Console/Application.php routines. Also would need to include lib/private/Setup.php. The bug on is_writable must still be prevalent in PHP 8.2. Also saw this as well: Write errors for nfs mount

The NC version installed must be the latest – version 27. Setup doesn’t reveal which version is installed.

[ernolf]

@52Buickman

I ran into this

Does on nas1.local.dom exist a user “apache” that owns the folder /mnt/vol1/nfs1/export/home/common/NextCloud ?

if yes, is its numeric user id the same as the numeric user id on nc2?

run:

id apache

to find out.

Much luck,
ernolf

[52Buickman]

Thanks for your reply. The NFS server doesn’t care who the user is as long as the user is defined on the NFS client (in this case the NC server). What is stored on the filesystem is the related ID number of the user. The NSS is relied upon to resolve the alpha name to ID number. If that NFS filesystem is mounted on another NFS client with another name associated to that ID number, the name will resolve to that name. As illustrated above, the “apache” user is able write to the NFS filesystem.

The problem is with PHP 7.x through 8.2 where is_writable() function has a bug related to NFS filesystems. What I’ve seen as a fix is to just comment out the validation routines using is_writable(). I’m doing that on the Setup.php but will look to implement a workaround (possibly just using fopen() and unlink() on a temporary file which supposedly works). I’ll have to setup a test instance to work out a solution and effectively test it. It will be slow as I’m not that proficient in PHP programming This is a good learning experience, though this bug should have been resolved by either PHP and/or NC/OC.

[ernolf]

@52Buickman

The NFS server doesn’t care who the user is as long as the user is defined on the NFS client

That is right but php cares about that.

ernolf

[52Buickman]

Please help me to understand. PHP would have to depend on the OS/filesystem semantics which would be the same whether local EXT or network based NFS for the way it is presented by the OS to the application. The only exception would be a timeout, but this mount is hard mounted and shouldn’t be an issue.

If fopen(), fwrite() and fclose() would work, then is_writable() isn’t doing its job to correctly to stat the filesystem, thus the longtime bug.