flock issue on first run
I am running NFS for my nextcloud data directory with the following setting in my docker compose file.
volumes:
- /nextcloud:/var/www/html
It is mounted on my ubuntu VM
192.168.1.23:/mnt/array1/nextcloud/ on /nextcloud type nfs (rw,relatime,sync,vers=3,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.23,mountvers=3,mountport=2049,mountproto=udp,local_lock=none,addr=192.168.1.23)
When I start the container for the first time, I see the file
root@69ba8f3f7436:/var/www/html# ls -al
total 4
drwxrwxrwx 3 1001 1001 56 May 29 19:55 .
drwxrwxr-x 1 www-data root 4096 May 21 23:45 ..
-rw-rw-rw- 1 root root 0 May 29 20:09 nextcloud-init-sync.lock
And the entrypoint.sh seems to be hung due to NFS on the flock command.
root@69ba8f3f7436:/var/www/html# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 20:09 ? 00:00:00 /bin/sh /entrypoint.sh apache2-foreground
root 11 1 0 20:09 ? 00:00:00 /bin/sh /entrypoint.sh apache2-foreground
root 12 11 0 20:09 ? 00:00:00 flock -n 9
root 13 0 0 20:11 pts/0 00:00:00 /bin/bash
root 23 13 0 20:14 pts/0 00:00:00 ps -ef
root@69ba8f3f7436:/var/www/html#
It's odd that it is hanging on the flock -n (the -n should return right away and not wait). Are you certain locking is actually functioning between your NFS client and server?
There are a lot of factors that can impact locking with NFS on both the underlying host (client) and server. They're mostly out of the scope of Nextcloud and the Nextcloud image.
Since you're using NFSv3 make sure things like statd and lockd are active and running on both client and server. Firewall rules (and protocol choices) can be a factor too (i.e. locking is out-of-band in NFSv3 and thus uses its own ports).
This channel isn't equipped to do one-on-one debugging on individual NFS deployments. You can maybe try the help forum - https://help.nextcloud.com -- however this is more a general Linux/*nix matter so forums for the NFS client and server OS(es) are probably more relevant.