I have an NFS mount that fails at reboot. If I refresh the Dietpi-drive_manager shows right up.
Newbie, any help is appreciated.
what do you mean by “fails at reboot”?? Usually mounts are executed only if you access to folder first time. Means, after reboot the mount is not there. But as soon you enter the folder, it should be remounted.
When booting it says [FAILED], (in red), Failed to mount…the NFS mount
did you tried to access the file system after system was booted?
Yes. I have tried
I can only get there if I go into Dietpi_Drive_Manager and do a refresh.
pls can you have a look into journalctl for available error messages.
Not sure how much to post?
Mar 23 17:33:44 SkidsPi systemd[1]: mnt-nfs_SkidsBook.mount: Mount proce
ss exited, code=exited status=32
Mar 23 17:33:44 SkidsPi systemd[1]: Failed to mount /mnt/nfs_SkidsBook.
Mar 23 17:33:44 SkidsPi systemd[1]: mnt-nfs_SkidsBook.mount: Unit entere
d failed state.
hmm honestly I’m wondering why you system is trying to mount the share during boot. Usually this should not happen and the mount should be executed only if you try to access the share. Can you check if the mount is executed before or after an IP address was assigned?
pls can you past as well content of /etc/fstab/
It tries to mount post trying and then connecting to my VPN via openvpn.
\
Please use “dietpi-drive_manager” to setup mounts
#----------------------------------------------------------------
NETWORK
#----------------------------------------------------------------
192.168.2.2:/nfs/Public /mnt/nfs_SkidsBook nfs auto,_netdev,nofail 0 0
#----------------------------------------------------------------
TMPFS
#----------------------------------------------------------------
tmpfs /tmp tmpfs defaults,size=1023M,noatime,nodev,nosuid,mode=1777 0 0
tmpfs /DietPi tmpfs defaults,size=10m,noatime,nodev,nosuid,mode=1777 0 0
tmpfs /var/log tmpfs defaults,size=50m,noatime,nodev,nosuid,mode=1777 0 0
#----------------------------------------------------------------
MISC: ecryptfs, vboxsf (VirtualBox shared folder), bind mounts
#----------------------------------------------------------------
#----------------------------------------------------------------
SWAPFILE
#----------------------------------------------------------------
/var/swap none swap sw 0 0
#----------------------------------------------------------------
PHYSICAL DRIVES
#----------------------------------------------------------------
PARTUUID=27504eef-02 / ext4 noatime,lazytime,rw 0 1
PARTUUID=27504eef-01 /boot vfat noatime,lazytime,rw 0 2
UUID=64dce9c8-bb04-4c78-9d5b-2abb52e1a5ab /mnt/64dce9c8-bb04-4c78-9d5b-2abb52e1a5ab ext4 noatime,lazytime,rw,nofail,noauto,x-systemd.automount
ok I setup a small test environment with NFS Server and Client. Looks like the NFS mount is done before the network interface is online. Therefore the mount failed. I found a small workaround to have it fixed. for this you would need to adjust /etc/fstab and replace your network mount with the following line
192.168.2.2:/nfs/Public /mnt/nfs_SkidsBook nfs _netdev,nofail,noauto,x-systemd.automount 0 0
Now your system will not go to mount the NFS share during boot anymore. This only will happen as soon as someone is trying to access the share.
It’s quite interesting that on 3 of my DietPis, I have different options in fstab for the nfs. They all are in v6.28 amd fully updated.
Raspi3B and Odroid C1 have auto,_netdev,nofail
Rockpi4 has _netdev,nofail,noauto,x-systemd.automount
None of them is using the dump and fsck numbers at the end.
Nonetheless they all work fine, but I guess there was some change at some point in the releases.
trendy
I guess it has something to do with using STATIC or DHCP IP address.
If I’m using DHCP, NFS mount is failing during boot.
root@DietPi3:~# journalctl -u mnt-nfs_client.mount
-- Logs begin at Thu 2019-02-14 11:11:58 CET, end at Thu 2020-03-26 10:11:41 CET. --
Mär 26 10:10:42 DietPi3 systemd[1]: Mounting /mnt/nfs_client...
Mär 26 10:10:42 DietPi3 mount[427]: mount.nfs: Network is unreachable
Mär 26 10:10:42 DietPi3 systemd[1]: mnt-nfs_client.mount: Mount process exited, code=exited, status=32/n/a
Mär 26 10:10:42 DietPi3 systemd[1]: mnt-nfs_client.mount: Failed with result 'exit-code'.
Mär 26 10:10:42 DietPi3 systemd[1]: Failed to mount /mnt/nfs_client.
But if I switch to STATIC IP, the NFS mount will succeed.
root@DietPi3:~# journalctl -u mnt-nfs_client.mount
-- Logs begin at Thu 2019-02-14 11:11:58 CET, end at Thu 2020-03-26 10:31:22 CET. --
Mär 26 10:30:46 DietPi3 systemd[1]: Mounting /mnt/nfs_client...
Mär 26 10:30:47 DietPi3 systemd[1]: Mounted /mnt/nfs_client.
root@DietPi3:~#
I am using dhcp on all 3 of them.
I rebooted the Raspi3B which has options auto,_netdev,nofail and the mount is available immediately.
dietpi@raspi:[~]$ sudo journalctl -u mnt-nfs_client.mount
-- Logs begin at Thu 2020-03-26 11:09:30 CET, end at Thu 2020-03-26 11:11:13 CET. --
-- No entries --
can you have a look to journalctl to see at which stage the nfs mount is done? Because on my test system 3B+ it’s done right in the middle of assigned an IP address via DHCP. So for sure the NFS will fail without eth0 up.
btw: trendy
you provided an empty journalctl -u mnt-nfs_client.mount code snip. So I guess your mount point is different than /mnt/nfs_client
-- No entries --
Yes, it is /mnt/backup and you are right about it. The mount is happening before the dhcp transaction starts, hence it fails. The automated backup kept taking snapshots though and there was something inside the directory, thus my confusion.
I corrected the nfs mount line in fstab and now works properly! Thanks!
I added the topic to an old GitHub entry. Let’s see what MichaIng thinks on it.
Guys,
a permanent fix will be provided with v6.29.
That did it, Thanks.
Will that be permanent if I use the drive_manager to add more drives?
Really Appreciate the help. This has been a glitch for some time.
usually it should, at least if you did not touch this mount. Anyway it will be fixed permanently with upcoming DietPi release.
Yes, fstab changes for network drives are permanent, only physical drive mounts are rewritten when you open dietpi-drive_manager.
And yes I fixed it for next DietPi release, thanks to your report! We already added this fix for NFS pre-v3 and Samba for simply missed the code lines that are responsible for NFSv3 which requires a slightly different fstab entry.