I have Rocky Linux running smoothly and I can successfully mount an NFS share from my Synology via
sudo mount -t nfs 196.168.0.10:/volume1/music /mnt/music
However this share is only accessible via sudo, so for a directory listing I need to do
sudo ls -l /mnt/music
How can I mount the Synology share so that the normal user or at alest an admin user can access it?
Many thanks for any pointers!
You could set it as an automounted directory - which would allow ordinary users to access remote NFS shares by just accessing the automount mount point (assuming the perms of the files on the NFS share are readable by the user - which may a problem if you currently need to use sudo to list the mounted share contents …)
There is plenty of information out there on how to set up automounting NFS shares
That is not the issue here.
Permissions.
Every process and file has uid and gid. Files have (POSIX) permission bits for owner (uid), group (gid), and other.
In order to “list directory”, you need read (r) permission.
In order access files in directory (including cd to it), you need execute (x) permission.
Before NFSv4 things were basically that NFS client did send uid, gid, and gid’s that the uid is member of to the NFS server and the server did compare them to the uid/gid of file to find if user is owner, (member of) group, or other.
The most trivial option is to give read and execute to the other on everything:
sudo chmod -Rv +rX /mnt/music
NAS might serve both CIFS and NFS, so it could have other than POSIX permissions, which affects whether the above chmod does what it should.
I was hoping for a solution where at mounting time I give the credentials of a user on the other system (the NAS). Then thus user would used regardless which user I am on this system (the Rocky VM).
NFS does have “squash”. The more common version makes root of client look like nobody; strips root from special access. The other makes every client account look like nobody. If the server grants read, execute, and/or write to nobody, then every client user gets that.
On a client machine you do have “database”: accounts and groups. The NFS server has its own database, and it can be set to use that. It still gets the uid from client, but looks from its own database whether that uid is member of group that allows access. Naturally, these databases should be synced. (Typically, both machines would use common database, e.g. LDAP.)
There is “more secure” mode for NFS. In it both machines look at Kerberos for authentication. If the client user (account/process) has valid ticket, then they have access to what the ticket allows. This is opposite of “one logs in and all use”; each user needs own ticket. A main benefit is that root cannot access files, unless it gets a valid ticket too. The root can easily pretend (sudo/su/runuser) to be any account, but getting some user’s ticket should not be as easy.
Squashing did the job!
I am now squashing via “Map all users to admin” (in the external NAS setup) and now I can access all information.
One weird thing though is that mounting changes the owner and group of the mount folder! Before the mount I get with ls:
$ ls -ld /mnt/music
drwxrws---. 2 root operate 6 Aug 4 08:12 /mnt/music
(operate is a group I have created for my “working groups”)
However, after mounting I get:
ls -ld /mnt/music
drwxrwxrwx. 1 root root 144 Aug 4 14:52 /mnt/music
Why does the folder has not the group operate anymore? I still can (because of drwxrwxrwx I guess) access its content freely.
No, it doesn’t. After you do unmount you do see the “original” values again.
What happens is that on mount kernel does change what it shows as “/mnt/music”.
When nothing is mounted on it, you see directory “music” that is in directory “/mnt”
When you mount NFS, the “music” is a directory in NFS server.
The mount operation hides the local directory. In fact, if the /mnt/music had files when there is no mount, then they would be inaccessible, hidden, while the mount exists.
@james-p had a good point: automount
If you do add the following line to /etc/fstab
196.168.0.10:/volume1/music /mnt/music nfs defaults,noauto,nofail,x-systemd.automount,x-systemd.idle-timeout=300 0 0
and reboot, then systemd will automatically generate on boot a service that “watches” the use of /mnt/music
Whenever any process attempts to look into /mnt/music, the service will do the “mount -t nfs” – nobody needs to run the “sudo mount” explicitly.
Furthermore, if no process is accessing the share longer than timeout (300 seconds in above), the service unmounts the share.
I see. Good to know. Thanks.
This is super-cool! I had no idea that this is possible. So I can automount many shares and even if they are not available straight away, the system won’t complain a s long as I am not using them. That’s fantastic!
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.