Bug #15861

nfsv3 and nfsv4 have permission issues

Added by Phil Hunt over 4 years ago. Updated about 3 years ago.

Closed: Behaves correctly
No priority
Josh Paetzel
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


nfsver4, and nfsver4 running nfsver3 mapping has issues in 9.10

Using nfsver4 settings, without nfsver3 mappings, nobody:nobody is the only thing displayed, even if you set mapall fields

With nfsver3 mapping, there is no difference

With nfsver4 unchecked, the only permission shown is the mapall user/group.

If you try to chown a file on the export, you get 'operation not permitted'. On a QNAP or Synology, real owners can be changed and are shown correctly on the export.

Going in SSH to the Freenas box, a user CAN change permissions for local use, but they changed user/group does NOT show up on the NFS export

This severely limits use of an NFS mount for permission based access


#1 Updated by Phil Hunt over 4 years ago

  • File debug-freenas-20160609172145.txz added

#2 Updated by Josh Paetzel over 4 years ago

  • Status changed from Unscreened to 15

It almost sounds like this is working correctly.

NFSv4 will set all the ownership to nobody:nobody if the users and groups don't match on the client and server.

If you want regular permissions to work just use NFSv3 and set the share to be writable by whoever you want it to be writable by: You can set permissions and ownership of things over in the storage -> edit dataset screen assuming you are NFS sharing a dataset. I doubt you want to use mapall, as that just maps all the NFS client users to one user on the server side.

FreeNAS definitely has more flexibility than the synology, but with that power comes....ughh, I can't bring myself to say it.

#3 Updated by Phil Hunt over 4 years ago

Well, I think you are missing is that with nfsv4 UNCHECKED, I cannot change anything

With mapall set, I do get the user I specify, but without it, I get nobody:nobody, like v4 perms. Under either
case, I cannot chown the file to another user or group.

I try changing ownership, I get 'operation not permitted'. 

This is from a Centos6 client who has NFS mounted the share
and the gid/uid are the same on the freenas and centos6 systems. 

Like shown below.  Changing to same user works (since there is no change), but changing to another fails

  1. touch aa.aa
    #ls-rw-r--r--  1 philhu users  0 Jun  9 19:09 aa.aa
  2. chmod 666 aa.aa
  3. ls -al-rw-rw-rw-  1 philhu users  0 Jun  9 19:09 aa.aa
  4. chown philhu aa.aa
  5. chown huntp2 aa.aachown: changing ownership of `aa.aa': Operation not permitted#

#4 Updated by Josh Paetzel over 4 years ago

I might be missing something, but this sure seems how NFS works.

If you haven't set maproot then root is getting squashed down to nobody, and nobody (correctly) can't change the ownership of your files.

If you want to use root to do things to your files I suggest you set maproot=root.

#5 Updated by Josh Paetzel over 4 years ago

  • Status changed from 15 to Closed: Behaves correctly

I'm unable to see an actual bug here.

#6 Updated by Phil Hunt over 4 years ago

You are right, never thought to set maproot user to root. That makes it work correctly.

So, if I set NFSV4 and use nfsv3 mappings, it should give these permission like v3, but with v4 attributes/security?

#7 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Seen in changed from Unspecified to N/A

#8 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-freenas-20160609172145.txz)

#9 Updated by Dru Lavigne about 3 years ago

  • Target version set to N/A
  • Private changed from Yes to No

Also available in: Atom PDF