Creating a bug report/issue
DietPi version |
G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=21 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'
Distro version |
Kernel version |
Linux Server 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux
SBC model | Rpi4
Power supply used | UCTronics POE splitter
SD card used | None. 128GB Kingston SSD
Additional Information (if applicable)
- Software title | NFS Client
- Was the software title installed freshly or updated/migrated? | Issue started following upgrade to Bookworm
- Can this issue be replicated on a fresh installation of DietPi? Yes
Steps to reproduce
- Fresh install or upgrade to Bookworm
- Try to access existing NFS share on Synology NAS that I was able to access prior to Bookworm upgrade.
Able to connect to share
Dietpi Drive manager finds no available shares at the NAS’s IP:
If I put in the path manually and try to connect I get the following errors:
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.
On my Bookworm system this is still working with together with Synology NAS
Can you check following
showmount -e 192.168.0.10
Export list for 192.168.12.100:
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:
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:
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.
That happens to me when a dive is expected to be mounted and isn’t present. Assume it’s a time-out thing
I had this symptoms when my configured network share was not reachable.
we have 2 different issues.
problem for @nojwe seems to be solved
@aftensleuk pls can you share following
showmount -e <ip.of.your.nfs-sever>
root@HTPC:~# showmount -e 192.168.1.243
Export list for 192.168.1.243:
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.
I solved the issue a few minutes ago with a rather drastic method. I uninstalled nfs_client and nfs_server - which removed all settings etc.
Then I installed them again and reconfigured from the beginning. Problem solved now! Works flawlessly.
Not sure if this will help anyone in the future, but it’s worth noting that this issue could occur.
It would have been interesting to actually compare the configs before and after, but I am glad that this solved it for you.
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.
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.
Thanks! This solved the issue. I unmounted a drive pointing to a drive in the network I’ve forgotten I’ve moved!