> Power up, go through POST, hand over to boot devices and... nothing.
Agreed. I hate systemd. In particular I hate how it works - or more
specifically doesn't - with NFS shares.
Hi Julian,
Apologies if I was unclear, but this is not a systemd problem (And I'm quite fond of systemd, myself)
This is the BIOS failing to find anything to boot from. That's fair enough, but it's unforgivable that the bios just sits there forever at the same "Loading drivers" progress bar it's shown for about 20 seconds in normal boot, and doesn't tell the human why.
Server: Fixed IP 192.168.1.3 (named Zeus) - Synology DS216j NAS with
latest firmware
NFS Share location: 192.168.1.3:/volume1/DEMETER
Client: Fixed IP 192.168.1.2 (named Cerce) - Mint 20.2
Share mount point: /media/julian/DEMETER
ATM only using the fstab to mount it.
It /used/ to use .mount and .automount files but after being in hospital
for months I turned the PC on and the old way refuses to mount. The PC
was off so couldn't update in my absence.
Am now at the point where it /seems/ to mount - it appears as a mounted
volume - but refuses to let me view the content [open the mount point]
(all files I created) unless I am a root user.
Whether systemd or sys.v manages the mount is unlikely to be relevant. (I use fstab quite happily everywhere, and even though I know systemd remaps that transparently, I don't need to care. It works.)
If client root can see them, then they're being exported and mapped fine.
I suspect the users or their UIDs of the users differ between the owner of that dir+files on the HOST and the user on the client, and the current permissions on the host dir+files are set not to let the client user's UID access them. NFS does not pass the owner's name across to clients - if you "ls -l" those mounted files on the client, if the user is different or it just displays numbers instead of a username, you might be working without the right user.
Check the privs on the host's shared dir with "ls -l". Then the UID of that owner with ""id username"
If the uid of that user on the client computer differs, then it won't be able to see them. (Unless its privs are wide enough for group or world)
Fixes if so:
Host: Change permissions of that dir so that the client's user has read perms. (Unsafe, quick and dirty method: "chmod 777 /path/thats/shared" )
"Better": Change the owner of the files on the host to the uid of the user on the client(s) if possible, or the user's UID on the client so it matches the host. (I use fixed UID and GIDs for service accounts across dozens of servers when I know they'll be sharing stuff via NFS to avoid this specific issue)
(Whilst you can change the UID and GID of a user, I don't recommend it unless you also know how to change the uid/gid of all their files too. You can easily break a user's permissions this way.)
