Understanding NFS

LiquidPC writes: "ONLamp.com's Big Scary Daemons section has yet another great new BSD article, this one on Understanding NFS and using it in FreeBSD."

Comments

A printer and human friendly version

[Shiny Metal S.]

Here's a printer and human friendly version, for those of you, who don't like half-screen animated ads inside the text you try to read.

Corrections, pointers, and cautions

[angio]

A few things in the article deserve to be clarified. First, Lucas states that "One thing to note is that NFS uses the same usernames on each side of the connection." This is not accurate - NFS uses the same UIDs on both sides of the connection. If you don't have a unified UID space between your machines, you'll have .. issues.

Second, if you export NFS to the world, you're insane and deserve what you get. If you want remote filesystem access, use a secure protocol like the Self-Certifing Filesystem (SFS). SFS also avoids completely the problem of having a shared UID space.

Finally, his advice to mount your filesystems intr is good. But insufficient - also mount them soft, so that filesystem calls will eventually timeout if the server goes poof.

Re:Corrections, pointers, and cautions

[HalfFlat]

The "soft" mount option used often to be called the "corrupt" option.

The problem is that programs rarely check to see if a write() fails after a successful open(). When the file system moves around under them, they can fail to write important data in blissful ignorance. This can lead to files whose contents are essentially broken.

The fault doesn't really lie with NFS, so much as with the lage body of code which assumes write() calls to a file are more reliable than NFS soft-mounted file systems allow.

Generally speaking, using soft mount is asking for trouble.

Good starter article, maybe

[spacey]

I don't think this article qualifies as "understanding nfs". NFS is a hairy beast, and all this does is get you started from the userland point of view. What makes nfs so hairy is the numerous ways it can fail or at least not do what you expect.

-Peter

NFS Howto

[I Want GNU!]

There is already stuff about NFS! The NFS HOWTO can be found at http://nfs.sourceforge.net/nfs-howto/

Re:NFS does have problems...

[autechre]

For the Windows clients, I just use Samba . It gets the job done quite well, though to use encrypted passwords you do have to maintain a separate password file for it. It does have a facility to sync the *nix passwd file to its own, though.

For the other problem, you should look into the root_squash option.

Re:What about security???

[autechre]

As someone else has already mentioned, you could use the Self-certifying File System .

You could also establish an encrypted tunnel between the two machines using whatever implementation of IPSEC they have (Linux has FreeSWAN, OpenBSD has something built into the kernel, not sure about others). Then you could share stuff however you wanted.

We're currently using NFS to share our MP3 collections on our private network (behind the firewall/gateway), and it's not a big problem there. But for any network I don't trust (and I'm not very trustworthy :), I'd stay away from it.

Tip for better NFS performance in FreeBSD

[vrgngoddess]

Just a tip... by default, FreeBSD uses conservative NFS mounting options. Note that these work well when trying to interoperate with other Unixes; everybody speaks the lowest common denominator. You can use mount options to augment NFS performance but reduce interoperability somewhat. These options aren't necessary when you're working with one or two clients, but as your NFS installation grows, you'll find them helpful. They may or may not work with other operating systems; it depends on what those OSs support.

NFS is REALLY insecure. But there are secure Alt.

[oobeleck]

NFS has a long history of insecurities.(Link takes a little while to load...)
Also in the article he claims: "You can reboot a server and the client won't crash." Maybe not crash but at least with Solaris (in my experience) you hang the entire system during the reboot. Sometimes it comes back and sometimes it doesn't.
For a secure alternative that runs on *BSD/Solaris/Linux w/(2.4 Kernels) try out:
Self-Certifying Filesystem.
The authors do warn that it is in alpha stage but also claim they have never lost a file. VERY cool project.

And of course as the OpenBSD Journal has noted, SysAdmin Mag is running an article on Tunneling NFS over SSH.

You CAN have multiple lines for the same partition

[fist]

Comments about /etc/exports...
"There are no identifiers between the components of the line. Yes, it would be easier to read if we could put each shared directory on its own line, but we can't; they're all on the same partition. The FreeBSD team could rewrite this so that it had more structure, but then our /etc/exports would be incompatible with that from any other Unix."

What?!?! Did this guy even read the man page for /etc/exports? Of course you can have seperate directories from the same partition on different lines!! In the man page they have an example of it! Plus there is this comment lifted directly from the FreeBSD 4.5 man page for /etc/exports.

"Mount points for a filesystem may appear on multiple lines each with different sets of hosts and export options."

Michael's articles are usually of excellent quality, but I can't believe how many other mistakes he's made! The article is written to familiarize a "junior" sys admin to NFS, but only teaches them bad habits. Hopefully he'll do a little more research for his future articles.

Re:What about security???

[AtomicBomb]

I agree securing NFS is a hard problem in a hostile environment. Basically, NFS is wide open if you managed to root one machine. A group of my friends at university used to boot machines using linux bootdisk. Then, mimics other guys UID, IP etc to fool the NFS server. If you gain root after login, a clue-up sysadmin should be able to track you down... Boot floppy is the killer here. Well, you can say the computer guys should disable floppy booting option in BIOS. But, they cannot really do much as some student need to boot with floppy occasionally (we are in CSE).

Simple tricks no longer works when we switched to something more secure, AFS , in our case.... It is way more advanced than NFS. For example, as a normal user, I can authorise only a few trusted person to have access to one of my designated subdir.

SFS (was Re:Corrections, pointers, and cautions)

[angio]

Yup. SFS is still "developmentware," but it's the most stable developmentware you'll ever use; DM writes really solid code. I've been using it for more than a year to edit source code, listen to music, and generally access my school home directory from home (and from my laptop when I travel).

I haven't had any SFS problems for over 6 months, since 0.5i. But the notice is correct - your mileage may vary, and use with caution. I've seen SFS tickle bugs in the Linux NFS implementation, but the latest Linux NFS support is much improved over 2.2. On Open/FreeBSD, it's quite solid, IMHO.

For further info, browse the SFS-users mailing list. It's a good way to get a feel for the issues involved in running SFS.

(Obligatory disclosure: I'm not one of the developers, but my office is across the hall).

Security

[NWT]

For those who are interested in a more secure NFS, i found an interesting article about encypted NFS (via openssh) It's a good read, and really interesting! Unfortunately it's written for Linux, but it's easy to adapt it to *BSD. Check it out here!