NFS mounts not working after Bookworm upgrade

Creating a bug report/issue

Required Information

  • DietPi version |

  • Distro version | bookworm 0

  • Kernel version | Linux Server 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr 3 17:24:16 BST 2023 aarch64 GNU/Linux

  • Architecture | arm64

  • 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

  1. Fresh install or upgrade to Bookworm
  2. Try to access existing NFS share on Synology NAS that I was able to access prior to Bookworm upgrade.

Expected behaviour

Able to connect to share

Actual behaviour

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:

Extra details

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

Export list for

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
Export list for

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.*
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 prog 100003 vers 3 prot TCP port 2049 │
│ mount.nfs: trying prog 100005 vers 3 prot UDP port 55553 │
│ mount.nfs: mount(2): Permission denied │
│ mount.nfs: access denied by server while mounting │
│ mount.nfs: timeout set for Tue Sep 19 15:30:38 2023 │
│ mount.nfs: trying text-based options ‘port=2049,vers=4.2,addr=,clientaddr=’ │
│ mount.nfs: trying text-based options ‘port=2049,addr=’ │
│ 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 :man_shrugging:

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

1 Like

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
Export list for
/mnt/dietpi_userdata *
/mnt/server 192.168.1.*

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.

Hello @MichaIng

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.

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 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!

1 Like