Another issue with NFS is it has a bad rap for being hard to tune. It's one of those cases of having "too many knobs". The default installation of NFS on most systems is pretty fast. If you don't know what you're doing, you can make it crawl (on it's belly like a dog). If you do know what you're doing, you might be able to make it as fast as it comes out of the box. If you've wrote the code, I'm sure you can make it blazingly fast, but in doing so you potentially sacrifice data-integrity - which brings us to our next point...
NFS is usually run UDP. This leads to the fact that your client doesn't necessarily know that the server got it's request to perform a certain task, and vice versa. NFS attempts to correct for this itself, but in the past has had... "issues". It can be run over TCP, but at an obvious trade-off for speed. If you're on a reliable network with good hardware, you can run UDP NFS for ages and never see a problem - but it's a risk that is difficult to ignore. There are also other issues dealing with buggy / weird file locking, and numerous other oddities that come with attempting to access a network filesystem just like it's a local filesystem. I'll try not to ramble on about those for days. :)
So in summary, NFS comes from a simpler time when security wasn't at the front of everyone's mind, and achieving fast network transfers was expected to require a good bit of wizardry, and perhaps be a little unreliable. These days, we take a lot of those things for granted. SMB (for all it's other shortcomings) does address most of the issues above fairly well. It's not the world's fastest protocol, but it is relatively reliable and certainly doesn't have too many knobs. :) It's reasonably secure, as long as you're not running your server on one of those other OSes (you know...). SMB is not the answer to all problems, though. Always consider the right tool for the right job.
Since I mentioned it above, I'll touch on SFS very briefly. SFS is a variant on NFS that attempts to answer some of the problems that NFS causes. It's significantly more secure, and otherwise functionally very similar. If you ever get the urge to considering doing NFS over a public network, don't. At least use SFS.
Aaron S. Joyner
Mike M wrote:
On Fri, Apr 09, 2004 at 03:37:48PM -0400, Tanner Lovelace wrote:
Ralph Blach said the following on 4/9/04 3:12 PM:
My son has Apples computers at his school and they are using OSX. Here are my questions.If they're using OS X, then it's quite easy. OS X supports not only
What file sharing protocal does Apple use. Can linux be a file server to a group of apple machines. If , how?
Thanks
AppleTalk, but also Samba and NFS. Probably the easiest thing would be to
just setup samba on a linux box and have the OS X machines connect
that way. <Apple>-k from the Finder brings up the network connect
dialog. Specify "smb://hostname/path", username and password and you're
set.
Samba and not NFS?
I thought NFS was easier to set up on a Linux box than Samba. I run into problems with files ownership and permissions using Samba too,
but I think I need to tweak my Samba config or play with my /etc/groups
to remedy that problem.
1If OSX uses the same *nix file ownership rules and permissions as
Linux, then why not use NFS?
-- TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug TriLUG Organizational FAQ : http://trilug.org/faq/ TriLUG Member Services FAQ : http://members.trilug.org/services_faq/ TriLUG PGP Keyring : http://trilug.org/~chrish/trilug.asc
