.
SMB / CIFS / NFS - Grin with cat attached
Previous Entry Next Entry
SMB / CIFS / NFS Dec. 6th, 2007 05:52 pm
Samba doesn't share symlinks as symlinks. NFS, from what little I've read, seems to have no decent user-based security.

Obviously Windows won't handle symlinks, but how can I securely share a filesystem from linux to OSX and maintain symlinks as real?

(Why do I need to maintain symlinks? Because subversion gets very upset when it finds a regular file or directory where it thinks a symlink should be.)

From: babysimon
Date: December 6th, 2007 - 06:20 pm (Link)
sshfs?

NFS, from what little I've read, seems to have no decent user-based security.

It assumes that if someone can authenticate as user X on box A, they can also authenticate as user X on box B. If you can live with that and your network is reliable it should be fine.
From: ciphergoth
Date: December 6th, 2007 - 06:30 pm (Link)
Once again Simon gets in before me; sshfs is what I use.

(Does it work on OSX?)
From: babysimon
Date: December 6th, 2007 - 06:35 pm (Link)
I believe so, it works through FUSE, doesn't it?

http://code.google.com/p/macfuse/

Hope this is of some use

From: bondagewoodelf
Date: December 7th, 2007 - 10:41 am (Link)
The Samba server is linux and the client is OSX, right?

I don't know if OSX has a similar option, but the Linux kernel CIFS client
can be told to change this behaviour:

echo 1 > /proc/fs/cifs/LinuxExtensionsEnabled

will show symlinks as symlinks (but you must mount the FS as type cifs and not smbfs)

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

will show symlinks as the target they are pointing to

This settings is used upon the time of mounting, so you can even have the remote filesystem mounted twice, once with the option turned on, and once with the options turned off.

This is all assuming OSX supports CIFS as its own filesystem and not as SMBFS and assuming OSX actually has a similar option.

The LinuxExtensions do a little more than just the symlinks, biut if you google for this /proc setting you can probably figure it out yourself.

DUh, it's your own SMB server, isn't it?

From: bondagewoodelf
Date: December 7th, 2007 - 10:45 am (Link)
You can also turn off this option on the samba server!

Have this in your smb.conf in the relevant share(s) and restart smbd

follow symlinks (S)
          This parameter allows the Samba administrator to stop smbd(8) from following symbolic links in a particular
          share.  Setting this parameter to no prevents any file or directory that is a symbolic link from being fol-
          lowed (the user will get an error). This option is very useful to stop users from adding a symbolic link to
          /etc/passwd in their home directory for instance. However it will slow filename lookups down slightly.

          This option is enabled (i.e.  smbd will follow symbolic links) by default.

          Default: follow symlinks = yes

Re: DUh, it's your own SMB server, isn't it?

From: wechsler
Date: December 7th, 2007 - 12:34 pm (Link)
They still look like directories or whatever, which confuses svn, you just get permission denied.

Re: DUh, it's your own SMB server, isn't it?

From: bondagewoodelf
Date: December 7th, 2007 - 12:49 pm (Link)
You are right ;-(

Does OS X support what I proposed in my other reply?

Re: DUh, it's your own SMB server, isn't it?

From: wechsler
Date: December 7th, 2007 - 12:51 pm (Link)
Unfortunately it seems to be lacking that proc file

Re: DUh, it's your own SMB server, isn't it?

From: bondagewoodelf
Date: December 7th, 2007 - 12:57 pm (Link)
Attempt #3

Try this on the server

       unix extensions (G)
          This boolean parameter controls whether Samba implments the CIFS UNIX extensions, as defined by  HP.  These
          extensions  enable  Samba  to better serve UNIX CIFS clients by supporting features such as symbolic links,
          hard links, etc... These extensions require a similarly enabled client, and are of no current use  to  Win-
          dows clients.

          Default: unix extensions = yes