Slashdot Mirror

← Back to Stories (view on slashdot.org)

Understanding NFS

Posted by michael on from the things-man-was-not-meant-to-know dept.

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."

33 of 138 comments (clear)

  1. So who's NFS? by Anonymous Coward · · Score: 3, Funny

    RMS's sister?

  2. A printer and human friendly version by Shiny+Metal+S. · · Score: 3, Informative

    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.

    --

    ~shiny
    WILL HACK FOR $$$

  3. What about security??? by Anonymous Coward · · Score: 4, Interesting

    I'm appalled that he considers IP address matching to be a way of preventing abuse. Sure, his cable modem is a separate interface so he can use a firewall to block it. But what if you're on a large untrusted LAN and you want to share files between two machines? I have exactly this problem (I have a laptop and a desktop at university) and I'm still looking for a simple yet secure way to share between them without allowing anyone to just spoof the IP address (and preferrably without transmitting my secret plans for world domination over the wire in the clear).

    1. Re:What about security??? by autechre · · Score: 5, Informative

      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.

      --
      WMBC freeform/independent online radio.
    2. Re:What about security??? by The+Original+Bobski · · Score: 2

      You forgot to mention that is a SOLID week or three to set up Coda (give up your life in the mean time). Even when it works, it does so for only a minuscule subset of needs. The resources it consumes may not be worth it.

      While I admire the effort, Coda is far and away from addressing real world connectivity problems. rsync works just as well without the major headaches and overhead.

      --
      satire, n: 1) witty language used to convey insults or scorn; 2) a form of humor lost on most slashdot moderators.
    3. Re:What about security??? by AtomicBomb · · Score: 3, Informative

      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.

    4. Re:What about security??? by jayed_99 · · Score: 2

      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).

      You're lucky you're not on any network I've ever admin'd. In my mind, no end-user ever has a need to use a boot floppy. If they do, then that means the machine is broken and, ergo, they should come and find me.

      If they need to use a boot floppy -- perhaps to demonstrate some elegant 1.44MB proof of concept, then they can use a development machine on a development network. (Please read "development" as "I don't give a rat's ass; we blow them away every Friday anyway").

      In a production network, there is no reason that an end-user would ever need to use a boot floppy. Well, there is no legitimate reason that an end-user would need one. In fact, it's difficult to determine a legitimate reason that an end-user would need to use a boot floppy on a development network.

    5. Re:What about security??? by Ubi_NL · · Score: 2

      I always thought NFS meant "No File Security"

      --

      If an experiment works, something has gone wrong.
    6. Re:What about security??? by Electrum · · Score: 2

      I always thought NFS meant "No File Security"

      DJB calls it Network Failure System.

  4. Corrections, pointers, and cautions by angio · · Score: 5, Informative
    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.

    1. Re:Corrections, pointers, and cautions by Phexro · · Score: 2

      Quick pointers to NFS U/GID space solutions:

      * rpc.ugidd - easy, but insecure. can leak u/gid info to untrusted parties. only works with userspace nfs server in linux - don't know about other opsystems.
      * use the same u/gids on every server - almost certainly not an option.
      * use a shared PAM back-end, such as LDAP (what I use), MySQL, or PostgreSQL

    2. Re:Corrections, pointers, and cautions by HalfFlat · · Score: 3, Informative

      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.

  5. caveats by Alien54 · · Score: 2
    One thing to note is that NFS uses the same usernames on each side of the connection. My files are owned by mwlucas on the server, so they are owned by mwlucas on the client. This can be a problem on a large network where users have root on their own machines. To create a central repository of authorized users, consider Kerberos or NIS. On a small network, or on a network with limited administrators, this usually isn't a problem.

    Pre-planning is useful, as always

    --
    "It is a greater offense to steal men's labor, than their clothes"
  6. Good starter article, maybe by spacey · · Score: 2, Informative

    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

    --
    == Just my opinion(s)
  7. NFS Howto by I+Want+GNU! · · Score: 4, Informative

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

    1. Re:NFS Howto by edhall · · Score: 2

      That's the Linux NFS HOWTO. Although it gives some good background on NFS (and in more depth than the article discussed here) it's pretty Linux-specific when it comes down to the actual setup process. It's not going to give you any FreeBSD-specific information, and so is of limited usefulness in setting up for that system.

      I'm amazed that a comment that's arguably off-topic gets modded up twice as "Informative," but this is, after all, Slashdot.

      -Ed
  8. Re:NFS does have problems... by autechre · · Score: 3, Informative

    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.

    --
    WMBC freeform/independent online radio.
  9. Tip for better NFS performance in FreeBSD by vrgngoddess · · Score: 3, Informative

    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.

    1. Re:Tip for better NFS performance in FreeBSD by wadetemp · · Score: 2

      That was pointed out in the article... interestingly, using 99% of the same words and sentance structures your post uses.

      Coincidence? I think not. :)

  10. NFS is REALLY insecure. But there are secure Alt. by oobeleck · · Score: 3, Informative

    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.

  11. You CAN have multiple lines for the same partition by fist · · Score: 5, Informative

    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.

  12. SFS (was Re:Corrections, pointers, and cautions) by angio · · Score: 3, Informative
    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).

  13. Security by NWT · · Score: 3, Informative

    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!

    --
    Life sucks.
  14. Security issues .. by AftanGustur · · Score: 2


    I had alot of fun with NFS during my Univerity years. Sure it has some nice features as it's lightning-fast and stateless but it's totally unsecure, period.

    The NFS server has two parts, the authentication part and the data-server part. The authentication part authenticates based on the IP address of the requester, if successful, it will send the requester the 'key' for the export.
    After that, anybody can use that key to request files from the data-server part. And from any IP address!!

    There exist a very nice ftp-like tool that lets you play with NFS systems, enter the key manually or use the UID overflow bug to get root privs. And this is only the beginning of the fun !!

    Trust me, "Don't use NFS" unless you are running it on a network that is not connected to the rest of the world, and you trust everyone that has access to this network.

    --
    echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
    1. Re:Security issues .. by AftanGustur · · Score: 2


      Use IPSEC authentication (AH or ESP if you also need encryption).

      Try that for 3000 clients and your performance is toast !

      --
      echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
    2. Re:Security issues .. by unclefucknut · · Score: 2, Interesting
      Try that for 3000 clients and your performance is toast !

      1. Cluster your export points
      2. Use hardware accelerated encryption devices
      3. Ask yourself: do these 3000 clients really need access? And what part of the local file system do they need access to? I realize that querying 3000 users for their purposes is a bloody hard job now, but it should have been done in the first place. Follow the principle of least privilege.

      For an organization with 3000 external clients, security shoult be at the top of the TODO-list. Finding a hacker/spoofer among 3000 clients is like finding a needle in a haystack. If this scenario is yours, then please reconsider some major security face lifts...

    3. Re:Security issues .. by AftanGustur · · Score: 2

      What you are proposing is throwing huge amounts of money out the window to fix a broken protocol.
      Have you *any* idea what 3000 encryption hardware accelerators might cost ? (+ servers)

      The "Correct" way, from every standpoint is simply not to use NFS, but some other protocol that has the security parts you need. For example, as long as you can protect the authentication credentials, encrypting the contents might not not be as important.

      But, many have also taken the "more money" way, and the simplest path to follow there (from an administrational point of view) is simply to use microsoft.

      The scenario is not mine, but not many years ago, a lot of universities had this setup. There are a LOT of hackers there, and many have switched to microsoft CIFS now.

      --
      echo '[q]sa[ln0=aln80~Psnlbx]16isb572CCB9AE9DB03273snlbxq' |dc
  15. Re:NFS does have problems... by bogado · · Score: 2

    The root squash option is not enougth because you can aways su to the desired user after going into root.

    --
    []'s Victor Bogado da Silva Lins

    ^[:wq

  16. Latest SysAdmin Magazine by totallygeek · · Score: 2
    Check out the latest SysAdmin Magazine. It has an article about securing NFS using SSH.

    --
    Click here or here.
  17. This is incorrect information by Just+Some+Guy · · Score: 2
    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!

    The article is correct; only mountpoints (and not subdirectories) can be entries in /etc/exports. From the `exports' man page (emphasis mine):

    Each line in the file (other than comment lines that begin with a #) specifies the mount point(s) and export flags within one local server filesystem for one or more hosts.


    Furthermore, the only example given in the man page explicitly identifies the directories listed as mountpoints.

    Please don't moderate up comments that sound informational without actually checking your facts first.

    --
    Dewey, what part of this looks like authorities should be involved?
  18. Re:Bleak days, bitter nights, for *BSD by Melantha_Bacchae · · Score: 2, Interesting

    An AC writes:

    > We all know *BSD keeps losing market share but why?

    Um, because it is gaining market share?

    Apple, in their last quarter report, announced the sale of one million boxes of OS X (a *BSD OS) and two million systems with it on the hard drive.

    The new iMac, booting OS X by default, had 150,000 preorders.

    The new iMac is the top selling computer for all time at Amazon. It is outselling every XP PC on Amazon.

    Out of the top 25 bestselling computers on Amazon, 10 were Macs, and all Macs are now shipping OS X as the default booting OS.

    ZDNet ran this (http://techupdate.zdnet.com/techupdate/stories/ma in/0,14179,2659085,00.html) article about how the number of *BSD users will soon exceed the number of Linux users, largely thanks to OS X and Darwin. *BSD already has three times the number of Linux desktop users. (And if the Linux users aren't happy about this, they can just run out and make more Linux users and make Linux more successful on the desktop. Then we can have a fun race with them. ;)

    > An unremitting gloom hangs like a death shround over a once hopeful
    > *BSD community. The hope is gone; a mournful nostalgia has
    > settled in. Now is the end time for *BSD.

    Sorry to burst your tragic bubble (not really ;) but *BSD is currently in no danger of death.

    *BSD is in serious danger of growth!

    Oh, there is a doomed OS alright. It is an evil empire, built on a foundation that now crumbles and groans under its weight. This empire doesn't see the danger. It never will, until it is too late. A hero thrice thought dead (Apple, Next, *BSD), now reborn, arises to shatter its foundations.

    Beyond time, beyond terror, beyond death, Mothra:
    Your heart can reach...Life!

  19. Re:Robust????!?!?! by Arandir · · Score: 2

    I've only had NFS on my FreeBSD box at work for a short while. But I've had it on my Solaris box for three years now. For a while last year the server would crash and burn every hour or two. A very horrible situation that only got resolved when we threatened to send to the servers back to Sun via patriot missile. This went on for a week. Not once did it cause any of the Solaris clients to buckle or fold.

    p.s. I suspect that a certain Sun rep deliberately sabotaged our servers in order to generate support calls. Obviously he is no longer a Sun rep.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  20. Re:You CAN have multiple lines for the same partit by Dahan · · Score: 2

    Well, just because you can do something, it doesn't mean you should. NFS doesn't export directories--NFS exports filesystems. If you have a FS mounted on /share, and you export /share/somedir, you've actually exported all of /share, even though you may not realize it.