There have been no changes to permissions on my Synology NAS and can access the share through my laptop without issue. I’ve confirmed that NFS is enabled and have rebooted the NAS. The Raspberry Pis that I’m trying to connect to the share with all have the same permissions settings on the NAS.
For me this looks like your Synology does not share any NFS folder for this device. Have a look to your Synology if you have set an IP address restriction or similar.
For me this looks like this
root@DietPi3:~# showmount -e 192.168.0.10
Export list for 192.168.0.10:
/volume1/NFS 192.168.0.0/24
root@DietPi3:~#
Hello! I’m having a similar issue that occured after updating to Bookworm via the script published on Github. It worked flawlessly before upgrade. Now one of my Dietpi-machines and my Windows machine can’t access the NFS-drive on one of the other Dietpi-drives.
Exportfs on the faulty machine results in the following:
root@DietPi-Server:~# exportfs
/mnt/server 192.168.1.*
/mnt/dietpi_userdata
Here is the error message I get when trying to add the NFS-share from the other Dietpi-machine:
│ [FAILED] NFS mount failed with the following error output: │
│ │
│ mount.nfs: mount(2): No such file or directory │
│ mount.nfs: trying 192.168.1.243 prog 100003 vers 3 prot TCP port 2049 │
│ mount.nfs: trying 192.168.1.243 prog 100005 vers 3 prot UDP port 55553 │
│ mount.nfs: mount(2): Permission denied │
│ mount.nfs: access denied by server while mounting 192.168.1.243:/mnt/server │
│ mount.nfs: timeout set for Tue Sep 19 15:30:38 2023 │
│ mount.nfs: trying text-based options ‘port=2049,vers=4.2,addr=192.168.1.243,clientaddr=192.168.1.14’ │
│ mount.nfs: trying text-based options ‘port=2049,addr=192.168.1.243’ │
│ mount.nfs: prog 100003, trying vers=3, prot=6 │
│ mount.nfs: prog 100005, trying vers=3, prot=17
Still not sure what the actual problem is, but this appears to have been fixed after a number of Pi and NAS reboots and changing the NFS permissions on the NAS to reference IP addresses instead of hostnames. Doesn’t really make sense to me why this would have broken with Bookworm, but it’s working now so
The problem is dietpi-drive_manager command is very sluggish and it takes 4-5 minutes before the GUI is started now on both machines. Something is definitely up.
Can you try to remove the (anyway unused?) /mnt/dietpi_userdata export? I wonder whether the fsid=0 leads to the fact that no export outside of this directory can be mounted anymore with the NFS server version from Bookworm.
On one of the machines, dietpi-drive_manager takes forever to load (4-5 minutes). As soon as I uninstalled the NFS-packages, the drive_manger loads within seconds. This wasn’t the case before upgrade to Bookworm where it always loaded within seconds, even with NFS-installed. Even after freshly installed NFS, the issue occurs again. What would you think causes this?
nojwe explained this already: systemd tries to automount the drive once the mountpoint is accessed (which is what dietpi-drive_manager does) with a default timeout of 90 seconds (AFAIK). For this time, it hangs the whole system, which is what you see. Not sure about 4-5 minutes, probably the mount point is accessed multiple times or multiple mounts are affected, or I remember the default wrong.
There are x-systemd.device-timeout=Xs and x-systemd.mount-timeout=Xs mount option which can be used to change the timeout for a particular mount, but I am actually thinking to change network shares or even all drives away from systemd-automount to common auto mount at early boot. There is a netdev flag/option for network drives to defer their mount until after network-online.target has been reached. This target was not meaningful before (is not by default on Debian), hence this did not work well in the past, but for DietPi we changed it to become actually meaningful so that we can at least test this.
