Wednesday, November 18, 2009

Samba Unix Extensions and Following Symlinks with OSX Leopard and Ubuntu Hardy

Sorry for that title - just trying to help the Google bot help the future.

So here's the problem. When we upgraded the bulk of the Macs at work to Leopard, symlinks on the Samba share quit working. They still worked in Windows, and on Hardy clients, but not Leopard.

If you created an 'alias' in Leopard, then the Macs could follow it, but the Linux boxes not.

Lots of people have the same or similar issues -
A B C D E F

Turns out Leopard is the first OSX client to support Unix extensions in CIFS.
So the client ends up trying to follow symlinks *locally* rather than on the server. 'Dumber' clients like Windows or Gnome Nautilus smb:// don't do Unix extensions, so the server resolves the symlinks for you.

The 'fix' is to set 'unix extensions = no' globally in the smb.conf file.
Now the OSX clients won't get the unix info either, and the server will go back to resolving symlinks for them.

The drawback to this fix as I understand it is that SMB with unix extensions on is a complete replacement for NFS in that the full range of unix permissions can be provided to unix clients - it's not limited anymore. You would need some external system to keep UID/GIDs syncronized, but NFS has that issue too.

What I still don't understand is how to get symlinks to resolve to the correct spot on the server when unix extensions *is* on. E.G. if I was using a 'smart' linux client (like mount.cifs and the /etc/fstab file?) how do I get symlinks to work? Comments appreciated, as I've spent too much time on this issue at the moment anyway.

Brian

PS - I also found out that when you create an 'alias' in OSX on a SMB share, the file it creates is actually in Minchell and French format - see this page that talks about creating symlinks on Windows servers. That's what OSX does on a linux server as well. Weird the linux client doesn't follow it!

No comments:

Post a Comment