Hey folks,
A coworker wants to share drives between CentOS systems via SAMBA, which sort of seems pretty counter intuitive to me. But he says he's had troubles in the past with NFS. He was sort of short on details, but something about NFS not being reliable unless you enable NFS locking, but when you do that, you can end up in situations where if the server crashes it can cause the clients to hang too.
I've used NFS for years in other jobs and don't recall issues like this.
Thoughts?
thanks, -Alan
Alan McKay wrote:
Hey folks,
A coworker wants to share drives between CentOS systems via SAMBA, which sort of seems pretty counter intuitive to me. But he says he's had troubles in the past with NFS. He was sort of short on details, but something about NFS not being reliable unless you enable NFS locking, but when you do that, you can end up in situations where if the server crashes it can cause the clients to hang too.
I've used NFS for years in other jobs and don't recall issues like this.
Thoughts?
The usual: what were the *exact* errors? I've never seen problems, either.
mark
On Thu, 2009-11-26 at 10:15 -0500, Alan McKay wrote:
Hey folks,
A coworker wants to share drives between CentOS systems via SAMBA, which sort of seems pretty counter intuitive to me. But he says he's had troubles in the past with NFS. He was sort of short on details, but something about NFS not being reliable unless you enable NFS locking, but when you do that, you can end up in situations where if the server crashes it can cause the clients to hang too.
I've used NFS for years in other jobs and don't recall issues like this.
Thoughts?
---- having a server crash will cause all sorts of problems for the clients whether they are using NFS or Samba
I always set up server so that users can mount and use shares in their native format and actually use LDAP for absolute consistency in UID and passwords...
NFS mounts for Linux users Samba for Windows users Netatalk for Macintosh clients
their user id is always the same and their password is always the same.
NFS mounts via LDAP automount Samba mounts are typically handled by 'netlogon' script Netatalk mounts via LDAP automount
the shares, ownership, etc are always the same so even if a user moves from Linux to Windows, he still sees the same files with the same permissions.
You can use 'soft' NFS mounts to not hang the clients but in reality, an NFS server should never crash and rarely be restarted.
Craig
On Thu, Nov 26, 2009 at 10:14:56AM -0700, Craig White wrote:
NFS mounts for Linux users Samba for Windows users Netatalk for Macintosh clients
Wow, I didn't even know netatalk was still around! How does it compare to SMB on OS X clients? I'm thinking that, unless you have a pressing need for some particular netatalk option, that using Samba for those clients as well simplifies admin on the backend. IOW, what are the scenarios where netatalk is either strongly preferred or required over Samba?
--keith
Keith Keller schrieb:
On Thu, Nov 26, 2009 at 10:14:56AM -0700, Craig White wrote:
NFS mounts for Linux users Samba for Windows users Netatalk for Macintosh clients
Wow, I didn't even know netatalk was still around! How does it compare to SMB on OS X clients? I'm thinking that, unless you have a pressing need for some particular netatalk option, that using Samba for those clients as well simplifies admin on the backend. IOW, what are the scenarios where netatalk is either strongly preferred or required over Samba?
My guess would be: Macs with OS 9 or older ;-)
On Thu, 2009-11-26 at 09:40 -0800, Keith Keller wrote:
On Thu, Nov 26, 2009 at 10:14:56AM -0700, Craig White wrote:
NFS mounts for Linux users Samba for Windows users Netatalk for Macintosh clients
Wow, I didn't even know netatalk was still around! How does it compare to SMB on OS X clients? I'm thinking that, unless you have a pressing need for some particular netatalk option, that using Samba for those clients as well simplifies admin on the backend. IOW, what are the scenarios where netatalk is either strongly preferred or required over Samba?
---- I don't recall timing checks between AFP (netatalk) and SMB (samba) but I do recall that AFP was light years faster than NFS on the Macs when using the Finder (but similar speeds from terminal transfers). I gathered that there was a bunch of latency from copying files using Finder operations on NFS mounts.
Advantages of using Netatalk instead of Samba for Macintosh clients?
- File naming... Mac users don't have to follow Windows rules for filenames
- Spotlight searches (finally fixed I think in OSX 10.5.x)
- Dual resource fork support
- A lot less objections/critiques from Macintosh users
I didn't find it to be a whole lot of extra administrative effort to implement. Obviously you have to compile netatalk, setup the shares, etc. but I use the same directories, the same uid's/gid's etc. and so it is indifferent as to which networking protocol is used to access (NFS/SMB/AFP).
Craig
I think the file locking only causes a problem with windows clients because of certain files types such as Access databases (.mdb) wanting to lock the file so that other users don't open the same database and corrupt data, for example.
On Thu, 2009-11-26 at 20:22 +0000, James Bensley wrote:
I think the file locking only causes a problem with windows clients because of certain files types such as Access databases (.mdb) wanting to lock the file so that other users don't open the same database and corrupt data, for example.
---- it's advisable to disable oplocks for those files...problem solved
http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/locking.html#id26...
Craig
-
Alan McKay -
Craig White -
James Bensley -
Keith Keller -
mark -
Rainer Duffner