Yes, I oversimplified things. The issue is that AUTH_SYS/AUTH_UNIX does not support NFSv4. AUTH_SYS uses the UID, not the name, so the mapping fails. So, when RPC uses AUTH_SYS, NFSv4 is SOL.
http://thread.gmane.org/gmane.linux.nfsv4/7103/focus=7105 Supposedly. at least on the client side, this has been fixed somewhere upstream. However, the server side is not. https://bugzilla.linux-nfs.org/show_bug.cgi?id=226 Regardless, my point is that this is not a Solaris/Linux issue, as a Linux server and Linux clients would be in the same boat. On Mon, Dec 8, 2014 at 12:23 PM, Paul B. Henson <hen...@acm.org> wrote: >> From: Ian Kaufman >> Sent: Monday, December 08, 2014 8:54 AM >> >> No, what we are saying is NFSv4 and RPC are not compatible right now, >> and thus AUTH_SYS/AUTH_UNIX will not map UIDs by name, but by number >> over RPC. If you are not going to use Kerberos or LDAP, then you need >> to sync UIDs/UIDNumber in /etc/passwd. It's not that Solaris and Linux >> are incompatible, it's that RPC does not support NFSv4. > > Well, I don't think it's technically accurate to say NFSv4 and RPC are not > compatible, nor that RPC does not support NFSv4. > > It's really more of an issue that the NFSv4 protocol failed to address ID > mapping completely for nonsecure RPC methods. For secure RPC (such as > Kerberos), identifiers are passed over the wire symbolically as strings, and > the ID mapper on each side translates them to numeric identifiers. However, > for insecure RPC using AUTH_SYS, NFSv4 continues to pass raw uid/gid > identifiers over the wire. > > This limitation of the protocol renders ID mapping somewhat useless for > NFSv4 over insecure RPC :(. Ideally they could address it in v4.1 or v4.2 by > creating a new insecure AUTH_SYS_NAMES protocol, which would simply use > symbolic string identifiers over the wire like secure NFS does. I guess > there is not much interest or concern about this in the communities that > deal with NFS protocol specifications 8-/. Perhaps the majority of > deployments for people in decision-making capacity use secure NFS and thus > are not impacted by this deficiency... > > -- Ian Kaufman Research Systems Administrator UC San Diego, Jacobs School of Engineering ikaufman AT ucsd DOT edu _______________________________________________ OmniOS-discuss mailing list OmniOS-discuss@lists.omniti.com http://lists.omniti.com/mailman/listinfo/omnios-discuss