NFS Permissions issue - only root on linux client has access?

[RobRoy90]

I am trying to access shared folders on my Synology NAS (RS1221RP+) via NFS from a Linux (Ubuntu) client.

I have the shares on the Synology successfully mounted to respective folders on the client as follows:

Synology: Volume1/Movies is mounted on Ubuntu at: /mnt/movies
Synology: Volume1/TV is mounted on Ubuntu at: /mnt/tv

When I attempt to access the shares from the Ubuntu machine at /mnt/movies or /mnt/tv, I can only do so if I su to root. When root, I can cd into that directory and see the contents.

If I am using my normal Ubuntu user account, I get a permission denied error when I attempt to cd into either movies or tv.

Should I be using a specific squash setting on the Synology NFS permissions? If so, which one?

Thanks!

 

[Rusty]

How do the settings for NFS look like on Synology side?

 

[Wool0602]

I am encountering the same Problem at work on a RS1221. I can mount a share successfully on multiple clients but only the root account gets access. Other accounts get a "permission denied" error.

The NAS runs DSM 7.1.1-42962 Update 1
The NFS system Settings are the default ones, so maximum Version is NFSv3.
The share settings in /etc/exports are:

/volume1/testfolder 192.168.0.0/24(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

The file permissions on the share are 644, so every user should have read access.
I am running the same export settings on a Debian based NAS and mounted the share to the same client as the above. There I can access a 644 file without any problem from different accounts.

Does anyone have a suggestion on how to solve this problem?
Thanks!

 

[Rusty]

Does anyone have a suggestion on how to solve this problem?

Welcome to the forum!

Would it be an option for you to try and alter the insecure_locks parameter and rename it to insecure? Does that make any difference in the /etc/exports file?

 

[RobRoy90]

Here is what my NFS settings look like on the Synology side. My Google-Fu yesterday pointed towards the squash settings, but I tried "Map all users to admin" as well as others and didn't get any further. I have also opened a ticket with Synology support and if I get a solution from them, I will report back. In the meantime, I would appreciate any other ideas... THANKS!

 

[Wool0602]

@Rusty I changed the entry to insecure from the cli (is there an option for it in the gui?) and reloaded the nfs-server.service. I also remounted the share in the client, but the "permission denied" still persists.

Same as @RobRoy90 I tried different squash mappings yesterday. Strangely with the "map all users to admin" setting even the root account on the client could not open the files anymore.

 

[Rusty]

Here is what my NFS settings look like on the Synology side. My Google-Fu yesterday pointed towards the squash settings, but I tried "Map all users to admin" as well as others and didn't get any further. I have also opened a ticket with Synology support and if I get a solution from them, I will report back. In the meantime, I would appreciate any other ideas... THANKS!
View attachment 12011

And if you disable "asychronus"?

 

[Rusty]

I also remounted the share in the client, but the "permission denied" still persists.

Have you tried to make the change and then stop/start NFS service (via gui for example using the check box)? Make sure that the exports file remains with no _locks. Try and access the mounts after that.

 

[Wool0602]

Have you tried to make the change and then stop/start NFS service (via gui for example using the check box)? Make sure that the exports file remains with no _locks. Try and access the mounts after that.

I just tried it and the Problem still persists. I changed the /etc/exports to insecure, saved it, restarted the NFS service using the checkbox in the gui and remounted the share on the client. After restarting the NFS service the entry in /etc/export did not change back to insecure_locks.
But every time I edit anything in the nfs share settings through the gui (like toggeling asynchronous -- that btw sadly did not resolve the problem) the entry in /etc/exports got rewritten to insecure_locks.

 

[Rusty]

I just tried it and the Problem still persists. I changed the /etc/exports to insecure, saved it, restarted the NFS service using the checkbox in the gui and remounted the share on the client. After restarting the NFS service the entry in /etc/export did not change back to insecure_locks.
But every time I edit anything in the nfs share settings through the gui (like toggeling asynchronous -- that btw sadly did not resolve the problem) the entry in /etc/exports got rewritten to insecure_locks.

Well that is expected tbh as the ui change affects the file. Guess the issue is somewhere else regarding permissions

 

[RobRoy90]

Here is the response from Synology support. Do I read this correctly in that they want me to change a UID?

Hello,

I understand you are only able to access NFS mounted shares while using root.

For uniform permission settings (all user accounts use the exact same privileges), you can select the Map all users to admin option for the squash in the NFS rule on the share, then configure the desired permissions for the DSM local admin account within Control Panel or File Station. All user accounts accessing the NFS mount at this point will have the same privilege as the DSM local admin for this specific share.

If you intend on having account-specific permissions, you need to setup a corresponding account within DSM (which can also be a domain/LDAP account) and give it its desired permissions. From there, you can use the no mapping squash within the NFS rule and either:

- change the UID on the NFS client to use the same ID as the DSM user

- use Kerberos authentication to map these accounts together

If the UIDs are mismatched, then you are likely able to mount the NFS share to the host but get denied access privilege when attempting to access the data.

To identify UIDs for DSM accounts as well as Linux clients in general, you can run the following command syntax through SSH:

id -u [username]

To change the UIDs for local accounts on a Linux client, run:

usermod -u [ID Number] [username]

Please let me know if you have any additional questions.

Thank you,

Andrew C.

 

[Wool0602]

@RobRoy90 Yes, they want you to create a local user on the NAS with the same UID as the user on the client with whom you ar trying to access the share and set the file permissions on the share accordingly.

But I do not like this response from Synology. From my understanding a NFS server does not need any knowledge about existing users. If I access the share from the client with whatever user I like it should check my current UID and GID against the ids of the owning user and group of the file or folder I am trying to access and if they do not match use the set permissions for the "everyone" category.

 

[Wool0602]

I created a support ticket with Synology myself. I keep you posted...

 

[andrewbeer]

@RobRoy90 Yes, they want you to create a local user on the NAS with the same UID as the user on the client with whom you ar trying to access the share and set the file permissions on the share accordingly.

But I do not like this response from Synology. From my understanding a NFS server does not need any knowledge about existing users. If I access the share from the client with whatever user I like it should check my current UID and GID against the ids of the owning user and group of the file or folder I am trying to access and if they do not match use the set permissions for the "everyone" category.

I got the same response. Did anyone find a solid answer to fixing this? TIA

 

[gpatlanta]

# groupmod -g 600 group01I got the same response. Did anyone find a solid answer to fixing this? TIA

Just joined the forum to post that this did help me in the end and how I got this to work for me.

I basically had the same situation. I am migrating some of my docker containers and heavy use applications from my Synology to a stand alone machine also running docker (namely Home Assistant and Plex). I went through a few pages reading to initially get the drives to mount and had the same issue of not having permission. Then came across this post which helped me.

In reading the above from the Syno support, I read it differently from updating the synology side of the user management and instead took it to mean the client machine. So I ensured my NFS was setup on my shared folders (this matched the original post however I did not have the "non-privileged ports" option checked and doubt that makes a different for this to work).

1. Verify the NFS permissions are set
2. Ensure the file folder also has permissions for a group that has a user you would map to from the client machine (in my case I had a docker user on both machines). Note: the user group ID and user ID on the client won't match and that's the problem.
   Note: make sure you get the qualified mounting info (e.g.; /volume1/[shared drive])
3. Log into your client machine (local or ssh, etc) as your administrative account
4. Change the group ID and user ID associated with the user you want to use to match your Synology ones (you may need to lookup this ID on Synology first using the cmd: id [username].
5. This page helped me to complete this task:
   

   How to (Correctly) Change the UID and GID of a user/group in Linux – The Geek Diary

   Changing the UID and GID of a user might seem a trivial task to most of the system admins. But it's not so trivial and it involves a lot more changes in the backend. In this post, we have outlined the exact steps to change the UID and GID of a user "user01".

   www.thegeekdiary.com
   
   

   ## backup the users and groups that exist:
   sudo  cp -p /etc/passwd /etc/passwd.bkp
   sudo  cp -p /etc/group /etc/group.bkp
   
   # change the group id (gid)
   sudo  groupmod -g [matching syno gid] [local group name]
   
   # change the user id (uid)
   sudo  usermod -u [matching syno uid] -g [matching syno gid] [local user name]

   
   Note: My settings are restrictive, so I had to sudo all changes including mounts and ID changes (your scenario may be different)
6. Mount the shares from Synology (not sure which of the following is best)
   
   

   sudo mount -t nfs [Synology NAS IP address]:[mount path of shared folder] /[mount point on NFS client]

   (ref: How to access files on Synology NAS within the local network (NFS) - Synology Knowledge Center)
   
   AND/OR
   
   - update the "/etc/fstab" file to include the new shares (ref:
   To view this content we will need your consent to set third party cookies.
   For more detailed information, see our cookies page.

   Accept third party cookies
   
   View: https://gist.github.com/jdesive/07139df545a6fd6adf03f6a3b9075814)