[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 30/10/2021 12:38, Simon Avery wrote:
On Sat, 30 Oct 2021 at 12:10, Julian Hall <linux@xxxxxxxxxxxx
<mailto:linux@xxxxxxxxxxxx>> wrote:
> 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)
I was just agreeing to the 'Hate computers' part.
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.That's why I think it's a permissions problem. For no good reason I can find it's suddenly decided I don't own any of my own files!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.
No idea how to do that.
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.)
Completely lost now. That's why I asked if there is a file that may be corrupt somewhere that tells a remote share who the owner is.
Julian -- “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