[SOLVED] nfs share fails to mount on boot but mount -a works fine

[charliepapa]

All the symptoms point to a problem with timing - like the network is not ready or something. I have tried all the suggestions for delaying the mount that I can find. Currently the fstab line is :
192.168.15.71:/mnt/manapool/media /mnt/banx/media nfs _netdev,soft,timeo=30,retry=5,rsize=8192,wsize=8192,tcp,intr 0 0

I would like to use fstab if possible. I tried some other solutions like a reboot cron job to run mount -a but that failed so I retreated from that rabbit hole to focus on trying to get fstab working because if I do something unconventional it will come back to bite me in the fuure. Any suggestions would be appreciated - or if there is a best practice solution I am happy to learn it.
The nfs server is TrueNAS - all permissions must be good since mount -a works.

 

[LnxBil]

Have you looked into the system log at the time of the error? Often there is some error about it documented.

 

[waltar]

soft,rsize=8192,wsize=8192

These options are really bad and should NOT defined at all, use instead
192.168.15.71:/mnt/manapool/media /mnt/banx/media nfs defaults,_netdev 0 0

 

[bbgeek17]

You can try adding debug:
server:/export/path /mnt/point nfs defaults,_netdev,debug 0 0


"man mount":

debug
           Turn on the debug flag. A version string and a list of filesystem parameters will be printed (these data are also printed if the parameters appear to be inconsistent).

Check log: journalctl -b | grep nfs
Check service state: sudo systemctl status NetworkManager-wait-online.service

Try using systemd unit to mount:
https://www.cloudnull.io/2017/05/nfs-mount-via-systemd/

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

 

[muzicman0]

I have had issues with Ubuntu and mounting smb drives a while ago. I created a root crontab that executes on reboot. I think it was something like:

@reboot sleep 10 && mount -a

It seemed to work for me, but I don't know if there are any issues associated with it.

EDIT: I see you tried the root crontab already. Leaving it here just in case you didn't try the delay with it as well. Of course you can also extend the delay if needed.

 

[charliepapa]

These options are really bad and should NOT defined at all, use instead
192.168.15.71:/mnt/manapool/media /mnt/banx/media nfs defaults,_netdev 0 0

thank you waltar I have changed my fstab as per your suggestion.
And I am happy to report that after a reboot the share is successfully attached.
I am not convinced that the change you suggested is the reason because I am sure that during my many iterations I had exactly that in my fstab file and it didn't work yesterday.
Perhaps it was just the new day - something either in the server or the client tweaked itself and decided to give me a break.

 

[charliepapa]

You can try adding debug:
server:/export/path /mnt/point nfs defaults,_netdev,debug 0 0


"man mount":

debug
           Turn on the debug flag. A version string and a list of filesystem parameters will be printed (these data are also printed if the parameters appear to be inconsistent).

Check log: journalctl -b | grep nfs
Check service state: sudo systemctl status NetworkManager-wait-online.service

Try using systemd unit to mount:
https://www.cloudnull.io/2017/05/nfs-mount-via-systemd/

---

Blockbridge : Ultra low latency all-NVME shared storage for Proxmox - https://www.blockbridge.com/proxmox

thanks for your reply - as mentioned in my other reply the mount is mysteriously working today but if it fails again I will add debug and also consider using systemd - thanks for the link.

 

[charliepapa]

I have had issues with Ubuntu and mounting smb drives a while ago. I created a root crontab that executes on reboot. I think it was something like:

@reboot sleep 10 && mount -a

It seemed to work for me, but I don't know if there are any issues associated with it.

EDIT: I see you tried the root crontab already. Leaving it here just in case you didn't try the delay with it as well. Of course you can also extend the delay if needed.

thanks for the advice - I did not try the delay but will do so if I go back to the cron job solution.