I?ve posted this same email to the linux NFS mailing list since I think it might
be client-side problem, but thought I might look for input here as well.
problem: when using chown as root on a nfs4 filesystem on newer linux releases
file owners get sets to nobody.
the user type doesn?t seem to matter (/etc/passwd, LDAP, Samba4)
setup: Server is FreeBSD 10 system with NFSv4 share.
Server and clients are all configured with the same idmap domain
Network users have consistent uid/gid on server and clients
clients with older linux releases work OK (Ubuntu 12.04, CentOS 5 and 6)
clients with newer linux releases do not work ( Fedora 20, Ubuntu 14.04,
Mint 16 )
clues:
1. working and non-working systems get to the same fchownat() system call with
the same arguments (via strace).
example (identical on working and non-working client):
...
fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0
close(1) = 0
close(2) = 0
close(4) = 0
exit_group(0) = ?
+++ exited with 0 +++
2. working system sends NFSV4 SETATTR request with owner set to: matlab at
nimgs.com and non-working as 11111 (via wireshark)
3. I can?t rule out misconfiguration. but I?ve configured as identically as I
could, and tried a lot of small vairations. these are my current settings (the
pipefs settings are the distro defaults)
Craig Yoshioka wrote:> I?ve posted this same email to the linux NFS mailing list since I > think it might be client-side problem, but thought I might look for > input here as well. > > problem: when using chown as root on a nfs4 filesystem on newer linux > releases file owners get sets to nobody. > the user type doesn?t seem to matter (/etc/passwd, LDAP, > Samba4) > > setup: Server is FreeBSD 10 system with NFSv4 share. > Server and clients are all configured with the same idmap > domain > Network users have consistent uid/gid on server and clients > clients with older linux releases work OK (Ubuntu 12.04, CentOS > 5 and 6) > clients with newer linux releases do not work ( Fedora 20, > Ubuntu 14.04, Mint 16 ) > > clues: > > 1. working and non-working systems get to the same fchownat() system > call with the same arguments (via strace). > > example (identical on working and non-working client): > ... > fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0 > close(1) = 0 > close(2) = 0 > close(4) = 0 > exit_group(0) = ? > +++ exited with 0 +++ > > 2. working system sends NFSV4 SETATTR request with owner set to: > matlab at nimgs.com and non-working as 11111 (via wireshark) >Yuck. RFC-3530 strongly encouraged use of <user>@<domain> names to identify users. rfc-3530bis (not yet an RFC afaik) "clarified" this to allow a server to return the number as a string (something done early in NFSv4 development for testing). This happened because Linux wanted to put the uid in a string so that NFSv4 mounted root file systems could be done more easily. (My understanding was that the client is now expected to understand a uid in a string, but I didn't think the server was required to accept it for a setattr.) There is a configuration option in the Linux nfsd that disables this for the Linux server side (sorry, I can't remember what it is and I don't know if this same setting changes client behaviour?). This is the first time I've heard of the Linux client putting the uid in a string (but I guess I'm not surprised). Hopefully there is a mount (or configuration) option that tells it to use <user>@<domain> for the mount. If there isn't such a beast, changing the server to accept the uid as a string is easy, although I thought doing so actually violated RFC-3530. (I'll admit I haven't looked closely at a recent draft of rfc-3530bis to see what it says. This document wasn't supposed to change the protocol, but just clarify it, however I think it has gone beyond that.) If you can find a mount/configuration option, please email with that. If not, email and I'll give you a patch that can optionally allow the server to handle the uid in a string. rick> > > 3. I can?t rule out misconfiguration. but I?ve configured as > identically as I could, and tried a lot of small vairations. these > are my current settings (the pipefs settings are the distro > defaults) > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org" >
Craig Yoshioka wrote:> I?ve posted this same email to the linux NFS mailing list since I > think it might be client-side problem, but thought I might look for > input here as well. > > problem: when using chown as root on a nfs4 filesystem on newer linux > releases file owners get sets to nobody. > the user type doesn?t seem to matter (/etc/passwd, LDAP, > Samba4) > > setup: Server is FreeBSD 10 system with NFSv4 share. > Server and clients are all configured with the same idmap > domain > Network users have consistent uid/gid on server and clients > clients with older linux releases work OK (Ubuntu 12.04, CentOS > 5 and 6) > clients with newer linux releases do not work ( Fedora 20, > Ubuntu 14.04, Mint 16 ) > > clues: > > 1. working and non-working systems get to the same fchownat() system > call with the same arguments (via strace). > > example (identical on working and non-working client): > ... > fchownat(AT_FDCWD, "/mnt/test", 11111, 4294967295, 0) = 0 > close(1) = 0 > close(2) = 0 > close(4) = 0 > exit_group(0) = ? > +++ exited with 0 +++ > > 2. working system sends NFSV4 SETATTR request with owner set to: > matlab at nimgs.com and non-working as 11111 (via wireshark) >I just looked at rfc-3530bis and it says that the client MUST accept the uid in a string for non-Kerberized mounts. For the server, there are two almost contradictory paragraphs. The first seems to say a server can accept uids in strings if it chooses to. The second states that it SHOULD support them for non-Kerberized mounts. (Here is the section.) I will note that this is currently an internet draft and not an RFC, so I think Linux has "jumped the gun". However I will email you a patch soon that allows this to be optionally enabled for the server. The 2 paras: To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of ASCII- encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value. A server SHOULD reject such a numeric value if the security mechanism is kerberized. I.e., in such a scenario, the client will already need to form "user at domain" strings. For any other security mechanism, the server SHOULD accept such numeric values. As an implementation note, the server could make such an acceptance be configurable. If the server does not support numeric values or if it is configured off, then it MUST return an NFS4ERR_BADOWNER error. If the security mechanism is kerberized and the client attempts to use the special form, then the server SHOULD return an NFS4ERR_BADOWNER error when there is a valid translation for the user or owner designated in this way. In that case, the client must use the appropriate user at domain string and not the special form for compatibility. rick> > > 3. I can?t rule out misconfiguration. but I?ve configured as > identically as I could, and tried a lot of small vairations. these > are my current settings (the pipefs settings are the distro > defaults) > > _______________________________________________ > freebsd-stable at freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe at freebsd.org" >