Slashdot Mirror
Experiences and Thoughts on SHFS?
eugene ts wong asks: "I was looking over SHFS, & I thought that this seems like a very good software package. If I understand it correctly, then it should be the defacto way to mount shares across a network. I never heard of it till today, though. What do all of you think of this? What kinds of experiences do you have? I am interested in hearing some of your stories. I heard that NFS isn't secure. How do they both compare? Would you recommend SHFS for small, medium & large businesses?"
I tried it, and I found it to be a bit unreliable. This was last fall... Random accesses on files were slow, and frequently it hung, leaving me with orphaned partitions I couldn't umount. Otherwise it worked ok -- I mean, it was easy to configure and whatnot, but performance wise when I tried it it was found lacking.
I have been using shfs for a few weeks now, and here are the pros and cons with my limited experience with it.
Pros:
(i) mounting remote filesystems over ssh is great, as you don't have to worry about opening up new ports.
(ii) read-only performance is good (I haven't had any problems).
Cons:
(i) definitely *buggy* (do not even think of using this for mounting partitions w/ critical data). For e.g., I mounted it read-only and by mistake opened a file with vim. When I tried to !wq, vim refused to write (obviously!), and I just escaped with a q!. Much to my chagrin, the file was gone--- I later figured that this was not a random bug; it was repeatable.
(ii) write performance (across a 1Mbps DSL conn.) *sucks*!
I tried using shfs but it didn't work very well (YMMV, I'm running a Gentoo 2.6.3 kernel) with my system. Frequent timeouts and the program had problems unmounting shfs mounts. I recently switched to using the "FISH" feature in KDE (fish://username@host/path_to_stuff/) and that has worked fairly well for my purposes.
Easy install, easy to use. Good stuff.
The place where I work is a UNIX shop, we use NFS all the time, because it operates reliably between various UNIX flavours. Every vendor has a robust implementation. We share terabyte-sized file systems, with no problems whatsoever. If you are worried about the security implications of NFS, there are other ways to combat them.
I've been using ntp on all the machines, but it doesn't seem to help much, there is still enough drift to cause make to fail. I'm not using any of the machines as an ntp server - though I have been thinking about that. Would that help? Especially given that one group of machines is rather a longish network trip from the rest (though only about three blocks in euclidean space).
I am not familiar with shfs other than a brief read of the website and this thread.
w/r/t NFS security, NFSv4 should solve most if not
all of the problems. Fundamentally two things always bothered me about NFS security.
RPC - NFS makes heavy use of sun-style RPC, requiring you to use the RPC libraries and the portmapper. This stuff has a bad reputation for security problems, eg, buffer overflows, and there is a lot of it, and it runs on random ports so it's difficult to filter/firewall/tunnel it.
no user credentials - NFS through V3 doesn't provide any user credentials - root on the client has access to all users' files on the mounted filesystem. There's no server-enforced security.
NFSv4 fixes the RPC/multiple ports problem.
I don't know about the user credential problem but i bet it fixes that too.
On to the quick-and-dirty:
In the past, I've set up a samba server and used the linux smbfs client to access it, and tunneled the whole business over SSH. It worked reliably, to the limited extent that i tested it (YMMV).
I don't really remember how well it performed - it was more of a proof-of-concept for me.
It's a pain in the butt, but you can at least fix the ports for NFSv3 in order to firewall:
/sbin/rpc.mountd --port ${RPCMOUNTDPORT}
/sbin/rpc.statd --port ${LISTEN_PORT}
/etc/modutils/nfs (or whatever works on your distro to set module params):
In your init:
And in
options lockd nlm_udpport=4001 nlm_tcpport=4001
For the above, be sure to run update-modules after in deb. Then afterwards, allow "RPCMOUNTDPORT, LISTEN_PORT, and udp/tcp ports 4001 (or whichever you choose) through the firewall.