[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 24/07/18 11:31, Julian Hall wrote: > I've done that and all three work.. do I assume the original .mount > files are now defunct and can be removed? No! Definitely don't do that! https://www.freedesktop.org/software/systemd/man/systemd.automount.html Even if it wasn't for the fact that the automount units act as a 'trigger' for the their underlying mount units it would still be bad practice to completely delete them: you've already systemctl disabled them and if you no longer wanted the functionality at all it would be wiser to systemctl mask them (which effectively 'hides' them) but leave the information still there. That way if you changed your mind in the future or wanted to explore different configs you could easily unmask them and bring them back into play. systemctl has tools to manage basically all this stuff once you know how to use it. Which reminds me - how long living is your Mint PC? By which I mean, has it had a lot of in-place upgrades through distro versions or was it a clean 18.3 install relatively recently. I ask because I fixed some odd startup issues on a Mint system last week that had been upgraded in place since the 16.x series and the problem eventually turned out to be fragments of the old crappy init system still hanging around and getting in systemd's way. It suddenly struck me you might be having the same issue on your system if it's of a suitable vintage which would explain a lot. What does this get you: apt-cache policy upstart If it says upstart is still hanging around, kill it with fire: sudo apt purge upstart && sudo reboot > I went into /media/julian and clicked on all three folders and they > mounted correctly so that works as you described. One issue is that > DEMETER has no lock icon on the folder but both HESTIA and PERSEPHONE > do. My guess is that's something to do with permissions / ownership. Yeah, you shouldn't have any problems sorting that out yourself I hope, it's obviously a permissions thing. Check your crappy Synology config, I'd trust that a lot less than the linux PC quite frankly. But otherwise, this is all working fine now right? > You know far more than me about the workings of Linux, but I have to be > honest I'm still not convinced on that score. All I know is that one day > the mounts came up at boot as normal, the only update I did that day was > to the kernel, and ever since the shares have refused to mount at boot. > No doubt something else happened that I am not aware of, but the only > change I actually made was the kernel update. Admittedly there is a chance you're still sort-of kind-of right - it could have been some miniscule but critical change to the version of the NFS kernel modules being loaded for example. But only kind-of right because nobody else seemed to be having the exact problem and carried on auto-mounting NFS with the same OS and kernel versions as you ¯\_(ツ)_/¯ Who cares eh? It works now! Cheers -- The Mailing List for the Devon & Cornwall LUG https://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq