[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 01/09/2021 15:55, comrade meowski wrote:
On 31/08/2021 20:38, Julian Hall wrote: <snip>Ok as you've now finally realised it's permissions on the NAS share - there was probably never anything 'wrong' with the Linux system in the first place - time to fix it properly.If you change the flags in the fstab line to:_netdev,auto,users,x-systemd.automount,x-systemd.mount-timeout=10,timeo=14,x-systemd.idle-timeout=1minThat will enable user mounts and automatic mounts... which will still not fully solve the problem. Don't worry about messing with nfs3 vs 4, the client and NAS are at least resolving that themselves by negotiating v3 as expected. v3 means no idmapping so permissions really do need fixing for this to work.Before you start blindly clobbering entire NAS shares with chmod/chown commands what does the following command return:id $user
julian@Cerce:~$ id #useruid=1000(julian) gid=1000(julian) groups=1000(julian),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),112(lpadmin),128(sambashare)
It will be interesting to see what groups you are in - you're probably "underprivileged" and are missing access to some standard linux groups that your user account should be part of. Even correcting that still won't fully fix your problem though - ultimately this has _always_ been a permissions issue and without correct permissions nothing is ever going to work out for you on a *nix system.I don't suppose your crappy little Synology supports ACLs does it?
I have no idea, so effectively no.
It was.. only on the 'sudo systemctl daemon-reload && systemctl start media/julian/DEMETER.automount' I messed up the syntax yesterday, although it already wasn't working..I would have a good long look at the permissions and owners/groups currently set on the NFS shares you want to access and check through them carefully so you know exactly what you're doing.CheersPS: your attempts at .automount were laudable but doomed to failure... You've got to understand what you're doing with this stuff, you can't just guess at syntax-exacting linux conf formats and magic stuff into working! Systemd mount units are delineated by hyphens. From my system:comrade@failbot:~$ systemctl list-unit-files | grep mount | grep vmware | awk '{print $1}' | sortvm-vmware.mount vm-vmware-mumblemot.mount vm-vmware-spiritditch.mount vm-vmware-wafflebot.mountThese are actually automatically made for me by the ZFS mount generator that runs in tandem with the systemd mount generator to individually generate all my systems mountpoints during synthesised boot. Sounds complicated but it isn't - all systemd based machines work the same including yours, just minus the ZFS bit. Note how the .mount units are all hyphen-delineated: these correspond to the ZFS datasets holding my vmware machines which in turn map to these folder paths./vm/vmware /vm/vmware/mumblemot /vm/vmware/spiritditch /vm/vmware/wafflebotSo for systemd mount/automount units in the future just use the filesystem path to the destination and swap the / for - to get your systemd mount unit naming convention. Make sense?Your media/julian/DEMETER.automount attempt should have been media-julian-DEMETER.automount
... but you also needed to make the file and it's corresponding .mount, systemd daemon-reload to make systemctl aware and then start/enable them too. As ever syntax has to be spot on otherwise Linux will barf on it.
-- “The great tragedy of Science — the slaying of a beautiful hypothesis by an ugly fact.” ― Thomas Henry Huxley -- The Mailing List for the Devon & Cornwall LUG https://mailman.dcglug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq