Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

NFS mounting tips for laptops Network
It seems to be a good idea to make NFS mounts soft and interruptible on OS X. If a server disappears, or you disconnect your laptop, your machine is royally screwed if you touch a hard mounted file system. Finder will lock up waiting for a response from the server, and you will lose the ability to launch new programs via Finder, you won't be able to unmount, and you won't be able to reboot (even with /sbin/halt).

So I use the automounter and specify the -i and -s flags to enable interruptible and soft mounts. This solution may not save you from the Finder locking up (you'll have to wait for the soft timeout), but if you have Terminal running, you can terminate stalled programs, such as the Finder.

But I discovered a memory of sorts in the kernel ... mounts once mounted as hard mounts will not demonstrate the behavior of interruptible or soft mounts when remounted. A reboot is required. Umounting and then remounting does not prove sufficient.
  • Currently 4.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)

NFS mounting tips for laptops | 3 comments | Create New Account
Click here to return to the 'NFS mounting tips for laptops' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
I wish it were true.
Authored by: theegor on Oct 26, '02 08:22:48AM

After further testing, I see that the behavior is mostly random. Most often interruptible mounts fail to interrupt. There doesn't seem to be much one can do because the mount_nfs command passes its parameters straight to the kernel (the source code lives in cvs under diskdev_cmds). The problem looks to be in the kernel.

But even so, when the kernel is fixed, the -i and -s parameters to make interruptible and soft mounts are very useful for laptops.

[ Reply to This | # ]
Be very careful
Authored by: mcramer on Oct 26, '02 10:52:03AM
NFS soft mounts are VERY dangerous for read/write filesystems! If you care about the data you are writing, do NOT use soft mounts. From the Linux (OS really doesn't matter) NFS HOWTO:


If a file request fails, the NFS client will report an error to the process on the client machine requesting the file access. Some programs can handle this with composure, most won't. We do not recommend using this setting; it is a recipe for corrupted files and lost data. You should especially not use this for mail disks --- if you value your mail, that is.

You'd probably be fine using it with a read/only MP3 collection or something like that, but in that case you're probably better off setting up DAV on the server and mounting the filesystem that way -- much easier access on the client, and you can realistically connect from anywhere.

[ Reply to This | # ]
Be very careful
Authored by: theegor on Oct 27, '02 07:50:54AM

Heh, you have just described SMB. The semantics of SMB are very similar to the semantics of NFS soft mounts. If the NT redirector sees a timeout on an SMB packet, it sends an error to the application. Some apps register an error handler and can deal with the error (I believe MS apps such as Word can absorb the error). But many can't, and they are terminated by the OS! Where as UNIX systems post a read/write error I believe (unfortunately many apps handle such errors ungracefully). SMB on OS X probably behaves like NFS soft mounts ... I haven't tested it yet though.

NFS offers you a choice for how you can lose your data. For hard mounts, your application thread will lock-up reading or writing to a file on a downed server. If this is Finder, you are screwed until the server returns. Otherwise reboot with data loss. For soft mounts, you can suffer a connection time-out, permitting you to recover Finder and the other threads interacting with the file server, but with potential data loss.

If there is a chance the server can return in a reasonable time (e.g. a corporate setting with home directories on the NFS server), you probably want hard mounts, but your machine will be highly unusable in the mean time.

[ Reply to This | # ]