Slashdot Mirror

I keep hoping that someone will come up with a better replacement, but CIFS/SMB will continue to work until that day comes.

It's called NFS v4. Kerberos for authentication, encrypted traffic, lower overhead, no passwords or password hashes sent -- ever.

In addition to the other replies regarding Coda and AFS, it should be mentioned that NFSv4 is a much-awaited improvement on NFSv3. It could turn NFS into a real alternative to SMB/CIFS in LAN setups and maybe even WebDAV in WAN setups (e.g. as in Apple's iDisk).

It supports ACLs, real/robust file-locking, encryption and authentication, compound RPCs to reduce network round-trips.

NFSv4

I mean its not as if anyone else on the network can change their UID and access anyone elses files via NFS, right?

You can control that to at least a host level by using NIS netgroups to restrict the filesystem exports.

NFSv4 has proper authentication and security baked into it, amongst many other wonderful things. The sooner everyone is using NFSv4 (or CIFS, if you like Spaghetti), the better.

NFSv4 looks promising to me. Of coure, that's what I thought two years ago as well. In any case, the goal for NFSv4 seems to be to take the best of NFS and AFS (and probably some other systems) and combine them.

The way we do it is that we have some underlying file store running on unix machines. At the moment we've got a couple Sun machines with large RAID arrays.

Then, to provide access to clients, we use Samba as a bridge to the Windows desktops and NFS for trusted linux clients; untrusted hosts can use SFTP or, if they just need read access, HTTP.

Having multiple storage nodes on multiple sites synchronized is a SAN, not client access, problem. NFS just doesn't provide multiple-node functionality. NFSv4 (link, link) may have some interesting features that could help; AFS was designed with multiple sites in mind and does intelligent caching and has other useful features over NFS but does have some limitations; and then there's things like IBM's Storage Tank which I haven't had a chance to look at properly yet.

Bottom line: If you have a flexible SAN infrastructure, you can use bridging nodes to provide access to the SAN tailored to whatever your clients require. The infrastructure is the hard part; with commodity packages like Samba client support is a much simpler seperate issue.

I'm sorry I can't address your question for good remote filesystems in the face of an unreliable network. My network has been relatively reliable and that's been a decreasing concern. Perhaps network reliability will be less of a concern for you, too, in future.

Lately, what I've been looking for is a remote filesystem that provides performance, security, flexibility, the latter in reference to being able to log into someone else's desktop machine and easily get my home directory mounted, whether from a big server up 24x7, or from my desktop.

Some have dabbled with DCE/DFS, but I've heard that's slowly dieing, ponderous to set up, performance suffers.

SFS looks intriguing, but I haven't heard pro or con about its performance. It appears to be secure and flexible.

NFS is an old friend and, yes, if the network or the server dies, a lot of local sessions will hang interminably 'NFS server not responding'. But, this doesn't happen as much as it did 5 years ago.

Right now we're running NFS v3, but the new NFSv4 looks like it has a better security model.

Finally (and you shouldn't even think about this if network reliability is an issue), simple block service like iSCSI looks promising as a way of interchangeably moving around from desktop to desktop and getting your same home directory no matter where you are. More, you could conceivably even get your own flavor of OS booting, be it Red Hat 9, Win2K, XP, Gentoo, etc. Don't know about its security; it's heavily dependent on a reliable, high-performance network, but looks like a good way to get the most storage for your dollar (NAS instead of SAN).

Perhaps the next version of NFS will be better in this regard...

It is.

"Maybe NFS4 is your answer?"

• NFSv4 home page
• NFS Version 4 Open Source Reference Implementation, for Linux and OpenBSD

--Bruce Fields

The upcoming NFSv4 standard will support strong authentication, encryption, and server-side access control. A group at CITI is working on a Linux implementation of NFSv4.

NFS can be configured to use various authentication methods on many OS'es, including DES & kerberos. Unfortunately, Linux NFS only supports the simple "trust the client host not to lie to you" default NFS authentication. This should change when NFSv4 is adopted.