[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 21/07/18 13:05, Julian Hall wrote: > Hi All, > > I would appreciate some guidance on this please. I've tried following > this website but I come unstuck on the specific filenames I need to use: > > https://cloudnull.io/2017/05/nfs-mount-via-systemd/ > > I'm using - as some already know - a Synology DS216j as my NAS. I have > three shares on it, DEMETER, HESTIA and PERSEPHONE. All three have the > shares exported via the Synology Diskstation Manager (DSM). The > permissions set for all three exports are: > > Client: 192.168.1.0/24 > Privilege: Read/Write > Squash: map root to admin > Asynchronous: Yes > Non-privileged port: Allowed > Cross-mount: Allowed > > These work for the Raspberry Pi I have [had] running Kodi and the smart > functions of my BD player which displays movies and pictures from the NAS. > > The perennial problem is that since kernel 4.12.* the NFS shares will > not mount from the fstab at boot. I have to run 'sudo mount -a' every > time; that works flawlessly so there is obviously a problem with the > boot process. This website seems to offer the solution but creating the > unit mount files for my case are giving me a headache. Taking DEMETER as > an example: > > Server IP: 192.168.1.3 > Server name: Zeus > Share name: DEMETER > fstab entry: 192.168.1.3:/volume1/DEMETER /media/julian/DEMETER nfs > > The unit mount file at the moment is named > '192.168.1.3-volume1-DEMETER'. Content of the file is: > > [Unit] > Description=Demeter Zeus > After=network.target > > [Mount] > What=192.168.1.3:/volume1/DEMETER > Where=/media/julian/DEMETER > Type=nfs > Options=_netdev,auto > > [Install] > WantedBy=multi-user.target > > I've tried 'Zeus' instead of the server IP but that made no difference. > I am really scratching my head at this point. This is still haunting you then I see! You name the new mount unit after your *local mount point* and not the remote path, so your unit file should be at: /etc/systemd/system/media-julian-DEMETER.mount And NOT: /etc/systemd/system/192.168.1.3-volume1-DEMETER Make sense? You want the result to be the Synology NFS share mounted at MINTBOX:/media/julian/DEMETER I believe. I've just tested this on a Mint 18.3 VM which hopefully should be very close to your setup, presuming you've not upgraded to Mint 19 yet. The NFS server in my case is Ubuntu rather than a Synology though, hopefully that won't make too much difference. 1: comment out *all* fstab NFS entries on the client 2: remove all other new systemd files and edits you've done 3: unmount all NFS shares or just reboot to start fresh 4: create the file /etc/systemd/system/media-julian-DEMETER.mount containing: [Unit] Description=NFS lazy test After=network.target [Mount] #What=failbot:/export What=192.168.1.3:/volume1/DEMETER #Where=/media/ghost/FAILBOT Where=/media/julian/DEMETER Type=nfs Options=_netdev,auto [Install] WantedBy=multi-user.target 6: sudo systemctl daemon-reload 7: sudo systemctl status media-julian-DEMETER.mount 8: sudo systemctl start media-julian-DEMETER.mount 9: ls -alh /media-julian-DEMETER The systemctl steps 6-8 will give you lots of useful info as they run - I've left my original entries as comments so you can see what worked for me. Hopefully this will just work first time if I haven't typoed anything - double check as you enter it though obviously. I'd avoid using /media as a mount point though, considering it's history of being used for automatic external mounts... Why not mount the NFS share somewhere more sane like your home directory? This method will also automatically mount the NFS share during boot every time which is I think what you wanted all along - I'm not convinced you do really want that though. You really should just let systemd mount and umount on demand (forced NFS umounts on unreachable servers are bad), but one thing at a time I guess. See how you get on. Cheers -- The Mailing List for the Devon & Cornwall LUG https://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq