[OmniOS-discuss] NFSv4 id mapping only working on client but not server?
Paul B. Henson
henson at acm.org
Mon Dec 8 21:42:32 UTC 2014
> From: Ian Kaufman
> Sent: Monday, December 08, 2014 12:37 PM
>
> 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.
I apologize for being a pedant; it's a character flaw :). Your wording implies that you cannot use AUTH_SYS with NFSv4, which is not true. NFSv4 works perfectly fine with AUTH_SYS as long as you maintain synchronization of uid/gid's on both sides. I would pick NFSv4 with AUTH_SYS over NFSv3 with AUTH_SYS. Both require that you maintain uid synchronization, so it's not like you're gaining something by falling back, and why miss out on the other features of NFSv4?
> 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
I don't know if I would call this "fixed" 8-/. They are basically just disabling the idmapper and passing raw uid/gid info at the NFS level to match the raw info at the RPC level. I guess it makes it less confusing in such a scenario, because you're always broken if they don't match on each side rather than only broken in some cases. An actual fix would be introducing an RPC mechanism using names such as AUTH_SYS_NAME, one of these days maybe I'll find the time to go hassle some NFS developers and see why they don't just do that and make everything simpler.
> 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.
Agreed. It is a deficiency in the NFSv4 protocol :(...
More information about the OmniOS-discuss
mailing list