Tighter NFS permissions


Recommended Posts

Hello.  I have been running unRAID 6.3.5 for about a week and have a question about NFS permissions.  I would like to set the NFS permissions on a share to be RW for a few *nix hosts but Read-Only for others.

 

To test, I created a share, set the NFS permissions to "secure" (and later "private"), but in both instances I was able to mount it read-only on a *nix server (Ubuntu x64).  Attempts to create files were met with "read-only file system" messages but I could read the files.  I would have expected the mount request to be denied.

 

Also, when I set the permission to "private" an additional option box called "Rule" was displayed.  What is the purpose of this Rule?  Can I use it to enter the IP addresses of the unix servers to be allowed R/W or RO permissions?  Thanks!

Link to comment

Here's a sample that will only allow the 192.168.2.* machines write access to the NFS share. Everybody else gets readonly

Additionaly, the options allow root user access from the 192.168.2.* machines. Everybody else gets mapped to uid=99

 

192.168.2.0/24(sec=sys,rw,no_root_squash,insecure) *(sec=sys,ro,insecure,anongid=100,anonuid=99,all_squash)

So, if the client IP fails to match whatever you have listed, they don't get access.

Edited by ken-ji
  • Like 2
Link to comment

OK, that's what I was looking for.  You say that "everybody else gets read-only", which is apparently the default.  Now it makes sense.  I'm coming from a Synology environment where if you don't explicitly allow RW or RO by IP address, then you can't even mount the share.  This is still acceptable.  Thanks for the reply.

Link to comment

Sorry if it wasn't clear (or I omitted the info)

With the share set to "Private", the default rule is

*(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash)

When you set something in the rule field, that rule takes over and the default is completely superseded.

So in my previous post, there are two rules stated in the field.

one for 192.168.2.*

the next for * (everybody else)

If you omitted the second rule, everybody would get access denied.

  • Like 1
  • Thanks 1
Link to comment
  • 5 years later...
On 7/21/2017 at 3:04 AM, ken-ji said:

Sorry if it wasn't clear (or I omitted the info)

With the share set to "Private", the default rule is

*(ro,async,wdelay,insecure,root_squash,all_squash,no_subtree_check,fsid=100,anonuid=99,anongid=100,sec=sys,ro,root_squash,all_squash)

When you set something in the rule field, that rule takes over and the default is completely superseded.

So in my previous post, there are two rules stated in the field.

one for 192.168.2.*

the next for * (everybody else)

If you omitted the second rule, everybody would get access denied.

I know I'm dragging this up from the past, but it's important; I've gone through this whole rigmarole as well, and I concur.

"Private" is the most restrictive level, and will deny any NFS access to the share unless explicitly allowed using a rule (as above).

You can use wildcard rules to allow various levels of access to an IP subnet or any non-specific IPs, although if using Private with a read-only rule for * then arguably you might be better off using Secure with additional rules for read-write for specific IPs.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.