Problem with Linux >= 3.3 as NFSv4 server
rmacklem at uoguelph.ca
Wed Aug 22 22:20:43 UTC 2012
Norbert Aschendorff wrote:
> Sorry, I was wrong :|. This time, the packets contain the numeric user
> and group IDs (in my case, 1000:1000). A pcap file with some NFS
> requests and responses can be found here:
> http://lbo.spheniscida.de/Files/nfs.pcap -- sorry for that
> misinformation in the previous mail :(
Ah, ok. Here's my version of the "numeric uid string" story for NFSv4.
During early testing, this was done, since none of the implementations
had the uid<->name mapping capability (rpc.imapd for Linux, nfsused for FreeBSD).
It was not allowed by RFC3530 for NFSv4.0.
Recently, there has been a push to allow this again, since it makes implementing
a NFSv4 root mount much easier. (When booting an NFSv4 mounted root, the userland
daemon can't be running, so either some mappings have to be hardwired or the numeric
uid/gid put in the string.)
I'm not sure if the draft of rfc3530bis (the updated NFSv4.0 spec that isn't yet
an RFC) stands on this, but I suspect adding support for this in the FreeBSD client
will come soon, at least for NFSv4.1.
Summary: Although it isn't allowed by RFC3530, numeric uid/gids in the string on
the wire probably will be allowed soon.
--> It could be argued that the new Linux kernel supports the new draft
of rfc3530bis and that this is not a bug.
I will cobble together a patch for this for the FreeBSD client soon. (I think
most of the code might still be there, but disabled.) It will probably
"understand" the numeric strings on the receive side and only send them
when nfsuserd isn't running.
I'll post to freebsd-fs@ (and try to remember to cc you) when I have such
a patch available for testing, rick
> freebsd-stable at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"
More information about the freebsd-stable