NFS share wont mount on boot

[corkscrew22]

I am running linux mint 20.1

I have a NFS shared dir on my network which i want to mount on boot it resides on a readynasduo the share is called Music

I have created a mount point using mkdir -m a=rwx called /media/NASduo/NASmusic

if I run the command sudo mount -t nfs (ip ad) xxx.xxx.x.x:/Music /media/NASduo/NASmusic

then it mounts fine and is accessible

I then add the following line to fstab

IP address:/Music /media/NASduo/NASmusic nfs defaults 0 0

but on boot it does not mount if i click on the icon for the share i get a message saying only root can do this. If i run sudo mount -a then it mounts as before.

What am i doing wrong?

[all41]

I am running linux mint 20.1

I have a NFS shared dir on my network which i want to mount on boot it resides on a readynasduo the share is called Music

I have created a mount point using mkdir -m a=rwx called /media/NASduo/NASmusic

if I run the command sudo mount -t nfs (ip ad) xxx.xxx.x.x:/Music /media/NASduo/NASmusic

then it mounts fine and is accessible

I then add the following line to fstab

IP address:/Music /media/NASduo/NASmusic nfs defaults 0 0

but on boot it does not mount if i click on the icon for the share i get a message saying only root can do this. If i run sudo mount -a then it mounts as before.

What am i doing wrong?

show your fstab
also show lsblk and blkid

[corkscrew22]

here you go note the NAS drive where the share resides has a fixed IP

fstab
=======
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda4 during installation
UUID=524a1a69-111e-48dc-a485-f56222c53870 / ext4 errors=remount-ro 0 1
# /boot/efi was on /dev/sda1 during installation
UUID=BF14-C61C /boot/efi vfat umask=0077 0 1
# /data was on /dev/sda3 during installation
UUID=e386a8ef-18c3-48d0-a065-beb2b9ce6d1f /data ext4 defaults 0 2
# /home was on /dev/sda2 during installation
UUID=8509aab7-8103-4d51-a4bc-fa433c9bcbad /home ext4 defaults 0 2
/swapfile none swap sw 0 0
# disk-2 after mint install
UUID=c397cce7-064f-470f-a5c5-eed72cd58ad0 /media/cem1/disk-2 ext4 defaults 0 2
#120GB SSD
UUID=948d9ed0-5f4b-4a88-ba0a-05d09f855b17 /media/120SSD ext4 defaults 0 2
#Indoscott shared folder
/media/120SSD/CAshare /media/120SSD/Indoscott_Share fuse.bindfs perms=0660:+X,force-group=Indoscott,nonempty 0 0
#NASDUO Mounts
IP address here :/Music /media/NASduo/NASmusic nfs defaults 0 0

lsblk
====
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 111.8G 0 disk
└─sda1 8:1 0 111.8G 0 part /media/120SSD
sdb 8:16 0 477G 0 disk
├─sdb1 8:17 0 190M 0 part /boot/efi
├─sdb2 8:18 0 76.8G 0 part /home
├─sdb3 8:19 0 290G 0 part /data
└─sdb4 8:20 0 100G 0 part /
sdc 8:32 0 931.5G 0 disk
└─sdc1 8:33 0 931.5G 0 part /run/timeshift/backup
sdd 8:48 1 59.5G 0 disk
└─sdd1 8:49 1 59.5G 0 part /media/cem1/BUP1
sr0 11:0 1 1024M 0 rom

blkid
====
/dev/sdb1: UUID="BF14-C61C" TYPE="vfat" PARTUUID="f192641d-f99d-4e4a-9562-af0afe97813c"
/dev/sdb2: UUID="8509aab7-8103-4d51-a4bc-fa433c9bcbad" TYPE="ext4" PARTUUID="76acd6ec-6ae0-4394-a98f-4cdd58577515"
/dev/sdb3: UUID="e386a8ef-18c3-48d0-a065-beb2b9ce6d1f" TYPE="ext4" PARTUUID="3fbdb05f-459f-4c3d-80b2-f45f39c9a0ab"
/dev/sdb4: UUID="524a1a69-111e-48dc-a485-f56222c53870" TYPE="ext4" PARTUUID="aa9e5fb2-117d-4f77-87d5-adb9a0edd549"
/dev/sdc1: LABEL="disk-2" UUID="c397cce7-064f-470f-a5c5-eed72cd58ad0" TYPE="ext4" PARTUUID="53c1c698-95c6-4d12-a909-7d7b43cd910c"
/dev/sda1: LABEL="120GB-SSD" UUID="948d9ed0-5f4b-4a88-ba0a-05d09f855b17" TYPE="ext4" PARTLABEL="sdd120gb" PARTUUID="dc59686c-eb10-473c-a8dd-d03dc26b43be"
/dev/sdd1: LABEL_FATBOOT="BUP" LABEL="BUP" UUID="E581-E4F7" TYPE="vfat" PARTUUID="58e01a94-01"

[phh]

Hi,

I'm experiencing something similar with my (own) fstab entries do not mount when boot. However i can mount them with "sudo mount -a" when system is up and running. I think this happened after a "apt upgrade".

/PHH

[rene]

As to poster directly above, if you are not talking about NFS but e.g. CIFS or even local filesystems it's a different issue altogether.

As to the NFS issue: I "unfortunately" can not reproduce on Mint 20.2 with either NFSv3 or NFSv4. The issue sounds like a boot time service ordering issue but whatever I try, all's up in the correct order. Assuming that your "ip address here" is an actual numeric IPv4 address such as 192.168.123.123 addressing issues are also out and I'm left advising what frankly I would advise anyway even though it's then in this case a workaround rather than a fix.

That is: so as to guard against an at boot unavailable network filesystem I very much advise to use the systemd automounter:

Code: Select all

192.168.123.123:/Music	/media/NASduo/NASmusic	nfs	noauto,x-systemd.automount,x-systemd.mount-timeout=10s,x-systemd.idle-timeout=10m

This has the share conceptually mount at boot; actually only when in fact accessed (and the idle-timeout has it unmount again after 10 minutes of inactivity; you may or may not care for that).

A said, I feel that better anyway but the issue was sort of interesting as to potential service ordering problem. Can however just not reproduce...

[AndyMH]

My synology mounts okay with fstab:

Code: Select all

#diskstation mounting under nfs
diskstation.local:/volume1/homes/andy /media/synology nfs vers=3,nofail,rw,users 0 0

So as rene suggests, probably a timing issue.

[corkscrew22]

As to poster directly above, if you are not talking about NFS but e.g. CIFS or even local filesystems it's a different issue altogether.

As to the NFS issue: I "unfortunately" can not reproduce on Mint 20.2 with either NFSv3 or NFSv4. The issue sounds like a boot time service ordering issue but whatever I try, all's up in the correct order. Assuming that your "ip address here" is an actual numeric IPv4 address such as 192.168.123.123 addressing issues are also out and I'm left advising what frankly I would advise anyway even though it's then in this case a workaround rather than a fix.

That is: so as to guard against an at boot unavailable network filesystem I very much advise to use the systemd automounter:

Code: Select all

192.168.123.123:/Music	/media/NASduo/NASmusic	nfs	noauto,x-systemd.automount,x-systemd.mount-timeout=10s,x-systemd.idle-timeout=10m

This has the share conceptually mount at boot; actually only when in fact accessed (and the idle-timeout has it unmount again after 10 minutes of inactivity; you may or may not care for that).

A said, I feel that better anyway but the issue was sort of interesting as to potential service ordering problem. Can however just not reproduce...

Thanks Rene, the above method works fine, its above knowledge level but I'm thinking maybe something to do with network availability on boot, but is as you say a better method of mounting a network share then all good. As an aside I didn't have this problem with an older version of mint and the same NAS a few years back.

I do have one question though I manually unmounted the share then edited fstab as per your instructions above i then ran

Code: Select all

sudo mount -a

this did not mount the share however once i rebooted it mounted fine why is this? is there a different command to run manually mount when the fstab uses systemd automounter ?

[rene]

It didn't mount as part of mount -a since the used option noauto specifically says "don't mount as part of mount -a" (including at boot)

The automounter arranges for an on-demand mount; it's mounted automatically whenever you access or even look at anything under /media/NASduo/NASmusic --- and only then which was the point here, i.e., it not mounting at boot at a point when apparently the network isn't "up enough" yet there. Yes, that's always better for a network-based filesystem anyway; an unreachable NAS otherwise "hangs" the boot.

[corkscrew22]

It didn't mount as part of mount -a since the used option noauto specifically says "don't mount as part of mount -a" (including at boot)

The automounter arranges for an on-demand mount; it's mounted automatically whenever you access or even look at anything under /media/NASduo/NASmusic --- and only then which was the point here, i.e., it not mounting at boot at a point when apparently the network isn't "up enough" yet there. Yes, that's always better for a network-based filesystem anyway; an unreachable NAS otherwise "hangs" the boot.

Hi another development everything has been working perfectly with fstab edited as you suggested to

192.168.2.9:/Music /media/NASduo/NASmusic nfs noauto,x-systemd.automount,x-systemd.mount-timeout=10s,

However we had a sudden power outage and the NAS malfunctioned can no longer access on the network. After that my desktop file manger became virtually unusable, for example if I clicked on the home folder it would take up to 5 mins for it to open.
I then edited the fstab by putting # in front of the above line, rebooted and everything worked fine again. ( NAS still offline)
I thought the automounter was supposed to take care of this sort of problem

[rene]

IIRC that means I now know that you use the Xfce edition of Mint or more specifically the Thunar file manager. Yes; I noticed that before as well; Thunar seems to enumerate locations it should not at its startup and moreover fails ungracefully if an e.g. network location isn't available. This would need to be classified a Thunar bug and the standard file managers for the other environments never had that issue for me (but I hardly ever use graphical file managers anyway).

[corkscrew22]

IIRC that means I now know that you use the Xfce edition of Mint or more specifically the Thunar file manager. Yes; I noticed that before as well; Thunar seems to enumerate locations it should not at its startup and moreover fails ungracefully if an e.g. network location isn't available. This would need to be classified a Thunar bug and the standard file managers for the other environments never had that issue for me (but I hardly ever use graphical file managers anyway).

Hi rene
I am running Linusx Mint 20.1 with Cinnamon desktop cw Nemo file manager I guess it has the same bug....

[rene]

Mmm. I never experienced that with Nemo although admittedly that might be partly due to me not using graphical file managers (much) anyway. Did you perhaps set a NAS-location as a favourite/bookmark in its lefthand sidebar?

I also just now remembered that in Thunar's case it was in fact also "solved" by switching the mount to CIFS rather than NFS (I experienced the issue in the context of an old NAS that would occasionally crash/hang). Being not exactly a CIFS fan that never set right with me but rather than investigate more I after a few times just junked the thing and didn't investigate further; perhaps tweaking an e.g. retry= NFS mount parameter would have done something semi-useful, say (although I doubt it; my disdain for CIFS notwithstanding, NFS isn't always exactly great either).

[corkscrew22]

Mmm. I never experienced that with Nemo although admittedly that might be partly due to me not using graphical file managers (much) anyway. Did you perhaps set a NAS-location as a favourite/bookmark in its lefthand sidebar?

I also just now remembered that in Thunar's case it was in fact also "solved" by switching the mount to CIFS rather than NFS (I experienced the issue in the context of an old NAS that would occasionally crash/hang). Being not exactly a CIFS fan that never set right with me but rather than investigate more I after a few times just junked the thing and didn't investigate further; perhaps tweaking an e.g. retry= NFS mount parameter would have done something semi-useful, say (although I doubt it; my disdain for CIFS notwithstanding, NFS isn't always exactly great either).

No i didn't create any bookmarks, they are automatically created in the network section of the left hand pane. They are also created on my desktop.
I used to use cifs eons ago to access the nas but switched to NFS which I found to be less "flaky" . Having said all this at least i know what the problem was and have a work around be editing the fstab . I have now fixed my NAS hopefully it does,nt happen again.

Of interest is my raspberry pi which is on the same network it did not have the same problem the NAS shares just disappeared. below is the entry in fstab of the RPi

192.168.2.9:/TV /mnt/Server_TV nfs noauto,x-systemd.automount 0 0

[rene]

Interesting; might then be some weird interplay with the x-systemd.mount-timeout=10s parameter? I.e., systemd in case of presence of that parameter not communicating up mount failures in the manner the in this case graphical filemanager expects to see.

Or some such. Will at least try to remember that if I ever see oddity going on there as well again...