Permissions on network mounted drives

I've managed to create some networked directories in my home network using fstab on the client machines and editing my exports file, so this isn't an instructions question, but I just wondered - when a user from a client machine enters a directory I've shared from the main computer, who does the main computer think they are (in terms of 'users'). Are they just 'other', or are they their user on the machine they're on?

If the latter, can I add them to a group on my machine so that they can access files which are denied to 'others'?

This part of you topic points to NFS.

NFS shares IP address restricted and you only have *ro or rw but as you can export the same folder several times for different IPs there is no problem in defining one IP ro and another rw.

A very good source of info on NFS

From the example exports it seems there is a possbility to map to user/group - but I have no idea how this works.

/srv/nfs/public,all_squash,insecure) desktop(rw,sync,all_squash,anonuid=99,anongid=99) # map to user/group - in this case nobody

Oh no, I'd hoped it would be simpler than I thought, yes, they're NFS all defined as rw in the exports file.

Yes, I saw that when I was setting them up, it's part of what prompted this question.

I supposed I'm just a bit baffled by the whole Users/Permissions thing. It seems to make perfect sense until some other machine accesses the files, then it seems like you've only two options, everyone or no one.

What I really want to do is what the NFS wiki hints at but doesn't explain (well, not enough for to understand anyway), which is to allow access not just from the IP, but from a particular user at that IP, but even if I were to specify this somehow, it still leave the question of whether it overwrites file permissions on my machine. Say I've got a directory where all the files are 700. I share that directory with NFS specifying rw access. Does that override the fact that my file permissions deny rw access to anyone but the owner?

I will admit that my in-depth knowledge of NFS is lacking :slight_smile:

To my understanding NFS does not implement access control in the sense of user/group - only IP based.

The implies that it is not possible to make a distinction of users.

My experience with NFS tells me that file permissions is inherited from the host exporting the files.

If the exported folder is owned by $USER then permissions on files by NFS in the folder will inherit the permissions of $USER.

I think this is why the importance of exporting the shares in separate structure using bind mounts to the actual shared folders cannot be emphasized enough.


I've already got the directories in bind mounts, so it sounds like I've done all I can security-wise. I just don't like having to have some of my files exposed to all users on one machine so that they can be accessed by specific users on other machines. Can't help feeling there's a better way round this issue of sharing directories on a local network - home server perhaps?

If you have sensitive files scattered among non-sensitive files - is not advisable from a security point of view.

Best practice is to keep anything considered sensitive in folders shared in a more restrictive way.

If the sensitive files is to be shared with a select user on a given computer - then the share should be mounted to a location on said computer where only the selected user has access.

According to below - NFS should be able to translate the userid from one system to the other - but that would require that a user is created with a specific ID on both systems. This can be done by provided the desired UID to the useradd command

useradd -u 1100 -U -m newuser


  • NFS is not encrypted. Tunnel NFS through an encrypted protocol like Kerberos when dealing with sensitive data.
  • Unlike Samba, NFS does not have any user authentication by default, client access is restricted by their IP-address/hostname.
  • NFS expects the user and/or user group ID's are the same on both the client and server. Enable NFSv4 idmapping or overrule the UID/GID manually by using anonuid / anongid together with all_squash in /etc/exports .
1 Like

Thanks, it looks like there should be something in the whole user-mapping process that can do what I'm looking for, might just have to play with it a bit.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by