NFSv4 On Linux is Broken
I’m in the process or building a new machine at work (more details later) and I stumbled upon a really annoying “feature” of NFSv4 on Linux (I’ve only tried RHEL4 and SLES10).
It seems you can’t expect to export the filesystem as you did with NFSv3 and earlier and then mount it in exactly the same way. Oh no, to quote their own words:
NFSv4 no longer has a separate “mount” protocol. Instead of exporting a number of distinct exports, an NFSv4 client sees the NFSv4 server’s exports as existing inside a single filesystem, called the nfsv4 “pseudofilesystem”.
That means if you share /export/tmp from a Linux host running NFSv4, in order to mount it you need to run “mount linuxhost:/ /mnt/foo“. This is illogical behaviour.
This also wreaks havoc with automountd on Solaris which doesn’t implement the Linux thinking as Solaris doesn’t. Solaris exports NFSv4 filesystems as it does with NFSv3 and earlier - none of this “pseudofilesystem” crap. What were the developers thinking?
One thing is nice to know, they’ve acknowledged this is a problem that needs fixing, but it seems no one has pulled finger just yet.
My solution - use NFSv3. Disabling NFSv4 on SLES10 is easy (see /etc/sysconfig/nfs), but I’ve not worked out how to do is on RHEL4 yet though
Search
Recommended Book
Related Entries
- HOWTO: Disable NFSv4 on RedHat Enterprise Linux 4
- HOWTO: Multi-boot Solaris, RHEL, SLES and Nevada
- Safari on Windows
- Microsoft Befriending Linux
- GPL vs CDDL, Again
- ISVs Want Solaris-like Consistency in Linux
- 64-bit Flash Player For Linux - Why?
- Linux Troll Attempts to Debunk ZFS
- ZFS: Rampant Layering Violation
- Links for 20 Jul 2009 - 15 Aug 2009
I simply write exports in NFSv3 manner rather than NFSv4
/folder (rw,no_root_squash)
What is written in this article is not correct and I don’t like the word “broken” which gives wrong impression to readers about linux due the bloggers’ ignorance. If you want to make nfsv4 in linux working the way it’s in Solaris, pls follow the below steps.
Let us assume, on the server, we want to share /home/nfs and that mounted on the client as :/home/nfs. Let us also assume, the nfsv4 root directory on server is /export.
- Bind mount /home/nfs on the server to /export/home/nfs.
- Configure /etc/exports on the server as below.
/exports gss/krb5p(rw,sync,fsid=0,cossmnt)
/exports/home/nfs gss/krb5p(rw,sync)
- On client mount the share using “mount -t nfs4 ip:/home/nfs mountpoint”.
–Sadique
Still seems pretty broken to me when you consider you don’t need to jump through these hoops for NFSv3 on Linux. Why the extra work? What advantage does this extra requirement give you over the NFSv3 functionality?
It’s not a question of what advantages of disadvantages extra requirement provide over nfsv3. It’s about the attitude of calling something “broken”. I do usually term something broken if it’s only unusable. Development of an opensource software is the hardwork of a lot of dedicated developers and it’s simply not good to call it broken just because you don’t know how to achieve certain things the way you are seeing it on other vendor’s implementation. My humble request is to read the nfsv4 RFC - http://www.ietf.org/rfc/rfc3530.txt - and judge based on that whether its implementation in linux is broken or not rather than making a judgement through comparing with other vendors.
This isn’t just a matter of between vendors: it’s a matter of inconsistency on the SAME OS - the Linux NFS guys even admitted as much. I happened to explain it in terms of different vendors as that’s how I encountered it.
As for the term “broken”: yes, it is a bit flippant (I’m not changing a 2 year old post now), but in terms of consistency, it is broken. It was also meant to provoke discussion at the time I wrote the article, not nearly 2 years down the road when the Linux documentation has improved significantly due to the increased usage, and after people have learnt to live with the inconsistency.
A lot changes in two years so your comments are perfectly valid and useful to anyone else who’ll stumble on this old post. Time has a wonderful effect on changing what is deemed “common knowledge”.
Hopefully people will stumble upon some authoritative documentation from a Linux vendor before they find this post though
Those who are willing to configure nfsv4 in linux the way it’s working in Solaris and NetApp filers, please refer my blog at http://sadiquepp.blogspot.com/2009/02/how-to-configure-nfsv4-with-kerberos-in_17.html
Linux NFSv4 implementation is broken by design!!
Somebody drank the pseudo filesystem koolaid and went wacky.
I challenge anybody to describe what (if any) enhancement the NFSv4 pseudo filesystem creates, or what problem it solved.
Perhaps the Linux NFSv4 functionality works in the sense that amongst Linux nodes it’s not literally dysfunctional but that is disingenuous as Linux NFSv4 ignores legacy functionality, abandons simplicity, while not adding any enhancement, and creating interoperability problems.
Seems to me the developer was looking to implement a pseudo filesystem more than NFS, and had a solution in search of a problem. It’s absurd! Having to share a RW filesystem twice (once RO, second as RW) to sooth the Linux’ism of the root level of the pseudo file system on the client side of Linux nodes. Utterly ridiculous!
The Linux NFSv4 requires more effort to understand and make work. That extra effort equates to more time, and time is money!