TheBonsai's Blog

About the days and nights of TheBonsai

Overestimated the advantages of NFSv4 on Linux

October 14th, 2008 by TheBonsai

At work, we have Oracle and -related systems on top of SLES10. When you need them to work in a shared environment (e.g. shared NFS disk), the user oracle and the group oinstall need the same user ID on all systems (naturally).

Unfortunately, the IDs of these entities depend on the point in the installation process where you install the SUSE orarun packet, since the UID is generated on the fly. This leads to trouble here and then (nothing serious, but it’s a bit of work to fix such an issue afterwards). Of course I think the installation procedure of the SLES orarun package should use a fixed ID here, but that’s something SUSE decides, not me (it tastes like a bug).

NFSv4 and its ID mapping – sounded interesting, and sounded worth to have a look. For this particular case, I was really only interested in the ID mapping, regardless other great features NFSv4 comes with. I made a test setup to check if it could help me out of these and similar issues.

The test setup was a simple server/client pair with OpenSUSE 11.0, to have a recent NFSv4 implementation. Named testusers on both systems existed, with different IDs of course. I first was excited, since everything worked as expected. The ID mapping did its job and I was able to work on both ends of the NFS connection, like there were no differences.

But one thing that bugs me: If you set file ownership numerical, or create a file using creat() or open(), the ID mapping doesn’t work. The situation is clear, of course. Numerical IDs are set directly, so the NFS server gets the numerical ID of the user on the client, can’t map it locally, and reports it as “NFS unknown user” over the link. That means, you (as generally mapped user) touch a file, and afterwards it belongs to “nobody”. A chown afterwards “fixes” that, of course.

What I would have expected from a usable implementation: That the machine which is commanded to set a numerical ID (for example by a simple creat() call) first tries to reverse-lookup the ID to a name and uses this name on the NFS link. If the reverse lookup fails, there’s no other way to behave like it does now, of course. But that additional lookup would help a lot. What do I need ID mapping for, if I can’t use it in 100% of the cases? If I need to use identical IDs or a central user database, I can stay at NFSv3 because the additional features NFSv4 brings don’t weight that much in our common installations. It really would have been nice if the implementation did that, unfortunately it didn’t (and – assumed the technical possibility is there – since the answer on the mailinglist was relatively clear, I don’t think it will be implemented).

Sooner or later, of course, NFSv4 will replace NFSv3. In which limited or full featured implementation ever. NFSv4 is the better protocol.


I want to make clear that I know the ID mapping is not meant as “end-user feature”. It’s needed to adapt the system to the name-only driven protocol. I just hoped I would have advantages using the mapping 😉

This entry was posted on Tuesday, October 14th, 2008 at 21:58 and is filed under english, Hobby, Linux, Work. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Leave a Reply