NFSv4: one step forward, three steps back

NFSv4 lets you route all your NFS traffic through a single, well-known TCP port (2049). Horray, it really works, it really gets rid of one of the stupidities in previous versions of NFS. It lets you use firewalls again.

NFSv4 maps every user on the client to 4294967294. In order to do user name translation it requires Kerberos. (Forget about keeping fixed UIDs like in the good old days — that doesn’t seem to work at all). Great for setting up an Enterprise(TM) service with 1000 clients. Absolutely fucking useless to just share a filesystem between two machines.

There’s a serious point to this rant.

When you’re designing a system that you want people to use, make the easy cases easy.

Don’t make me read through a dozen obscure man pages and half a dozen really obscure configuration files to just have the basic function working.

NFSv4 has so far been a 100% failure for me and for many many other people because no one thought about making the easy case easy.


Filed under Uncategorized

5 responses to “NFSv4: one step forward, three steps back

  1. Obviously a large Standards Committee Effortβ„’, with lots of participation from Large Enterprises and vendors who wanted to make sure that their own sacred cows were gored no more than their competitors’ by the formalities.

    The usability of work done by the IETF, ANSI and ISO (in particular) have dropped shockingly over the past decade or so. I’m old enough, as you likely are, to remember when an IETF standard meant “it works; go ahead and use it and/or implement it yourself.” Those days are as extinct as the middle class in America.

    “One step forward, a marathon back” is the cumulative trend here.

  2. I am NOT going to defend NFSv4 until my last drop of blood, clearly one size does not fit all (and probably simply cannot fit all).

    But still, come on, try to be fair. Setting up idmapd for static UID/GID mapping is a matter of 6 – 8 (at most) trivial configuration lines in /etc/idmapd.conf and your system (neither the server nor the client) does not even have to know what Kerberos is.

    Believe me, I am using NFSv4 with static UID/GID mapping for file sharing in my home network and the complexity of setting up this and Samba is roughly the same.

    • rich

      I’d really love to know how, because I could not work out how to do UID/GID mapping (a la NFS v3).

      The original problem I had turned out to be because the client (standard Debian) was not sending any domain or username. It was just sending UIDs as strings, eg. “1000” instead of “rich@domain”. idmapd was absolutely no help at all, even running it standalone with:

      rpc.idmapd -f -vvvv

      Another aspect to good software is making sure that when it fails (and even the best software fails sometimes), what is going on is visible and easy to understand, which idmapd certainly is not.

      • The problem is probably in the definition of “software failing”. For idmapd it is not considered a failure if it cannot find the UID/GID translation. This can happen a million times in a lifetime of a file server and it is indicated on the client side by setting the UID/GID value to (uint32_t) -2 (a.k.a. 4294967294).

        Yes, running rpc.idmapd with four -v could probably show even these events, but hey, you can probably dig out who actually wrote the piece of code and write him/her directly. This is one of the things I like so much on FOSS πŸ™‚

        As to your question, try to adopt the following configuration. This is the content of /etc/idmapd.conf on both the server and the clients:

        === /etc/idmapd.conf ===
        Domain =

        Nobody-User = nobody
        Nobody-Group = nobody

        Method = nsswitch
        === cut here ===

        The key is to keep the value “Domain” in sync on the server and on the clients. It is not a domain in the DNS sense, it is what used to be called the “realm” in Kerberos IV. Well, actually the whole idmapd configuration should be consistent on the server and the clients.

        You don’t have to have anything fancy in your /etc/nsswitch.conf, the usual local-only configuration (mostly “files”) is perfectly OK.

  3. Martin is right. It works just by setting up those lines. There is one more thing you need to change is to start idmapd service. By default is disabled in /etc/default/nfs-common file

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.