Mount with smbfs treats symlinks invalid

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Could you try to use the cifs module instead of smbfs ?

Which version does the ubuntu-server run ?

> Could you try to use the cifs module instead of smbfs ?
Same situation (unmounted smbfs, remounted with cifs)

> Which version does the ubuntu-server run ?
Dapper, smb 3.0.22

This is a feature that falls under the CIFS Unix extensions. The latest version of the cifs kernel modules implements proper support for these extensions.

Can you translate your answer, please?
Does it mean it's a feature that I can see symlink info through Samba?
Is the latest version of cifs not included in gutsy yet?
I'm confused.

On Mon, Aug 27, 2007 at 10:11:15PM -0000, markba wrote:
> Does it mean it's a feature that I can see symlink info through Samba?
Yes. But it seems that having a symlink pointing outside the shared
directory is pointless.

> Is the latest version of cifs not included in gutsy yet?
The latest version of the cifs module in gutsy properly implements the
CIFS Unix extensions, which means that symlinks and other unix
properties are correctly supported with the cifs protocol.

You can disable this by using the 'unix extensions = no' option on the samba
server.

OK, it's nice to have that symlink info, but this is not good if that particular folder is unreachable, see example:

user@gutsy-desktop:/media/lin01-public/music/all$ cd mp3
bash: cd: mp3: No such file or directory

Even if I turn 'unix extensions = no' on de server (and assuming the above problem is solved), this should not happen in my opinion: all folders should be reachable with or without the server setting. This is important for backwards compatability.

Because misconfigured symlinks can be a security exposure, discussing symlinks requires a little background:

If the client is Linux client, Samba server by default reports a symlink as a symlink not as a directory. The Linux client can get information on the symlink and follow it. Symlinks from within a network export (share) to paths outside of the share, especially absolute paths (e.g. like /etc/passwd) are usually a bad idea, but there are cases where they may be useful.

If you want to follow symlinks on the server, rather than have the client follow symlinks. You can turn off the Unix Extensions any of three ways:
1) "unix extensions = no" in the server smb.conf file
or
2) turning them off on the client before mount
      echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled
or
3) turning them off on the mount (cifs 1.50 or later, probably not in your kernel)
     mount -t cifs //server/share /mnt -o nounix

Also note that symlink following on the server can be disabled by "follow symlinks = no" in the server's smb.conf (rarely needed)

I don't think behavior on the client side has changed in a while here (other than the new mount option "nounix")

Note that smbfs symlink support may have problems. The cifs module has replaced smbfs ("mount -t cifs //server/share /mnt" instead of "mount -t smbfs //server/share /mnt"

nfs behaves the same way, ie the clients sees symlink.

Steve provided three ways to fix your configuration.

Thus I'm marking this bug as Won't fix.

Hi,

I still have problems with this on Gutsy

$ uname -a
Linux sbornia 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

$ cat /proc/fs/cifs/LinuxExtensionsEnabled
0

$ sudo mount -t cifs -o nounix,credentials=/home/renato/.smbcredentials,rw //cup/sp sp

And still see the symlinks as symlinks...

@rengolin. I have used the other solution, on the Samba server-side: 'unix extensions = no'. This is working OK for me. I have not tried the client-side solution like you have used, so I can not comment on that. Perhaps this is any help for you.

Hi, not at all, I don't have access to the server nor can ask the admins to change this policy company wide. Thanks anyway!

I have the same problem when 'unix extensions = yes' is set on the Samba server side. Server and client are both Ubuntu 7.10 (Gutsy).

If the symlink itself is the share, it can be accessed from the client, and it is followed correctly on the server. The symbol for the share in the clients GUI is not that of a link but that of a simple folder or file.

If the share is a folder and she symlink is inside the share, the symlink is displayed as a symlink on the client. It can't be followed on the server because the client tries to follow the link on the client itself. Usulally the target does not exist there and the link is displayed as 'broken', but it if a file with the targets name occasionally exists on the client, the link leads to a wrong file. That can be quite dangerous.

The problem only depends on the setting of 'linux extensions = yes' on the server; it is the same if the share is mounted with 'smbfs' or with 'cifs' on the client.

Setting 'unix extensions = no' on the server side seems to me not to be a good solution, for usually unix extensions = yes is needed for access rights administration. I hope that there will soon be an other fix for this bug.

I was able to follow symlinks once I used the nounix option in the cifs mount.

BUT it's still not clear to me what the "right" way to follow symlinks is when unix extensions is turned on.

I've tried with nounix and nolinux (as proposed by the cifs devs) and
changed the bit in /proc and got symlinks all the time. I guess I was
using a different version than the server and there could be some
issues (I know rsync does a lot).

Unfortunately, I can't control the server, but I moved all my stuff to
the same tree and now I don't have this problem anymore... Pity I
solved the wrong way... ;)

I'd no problem with symlinks.Then I've updated to Lucid Lynx, and now I discover this bug.
I've added the following lines to /etc/smb.conf :
follow symlinks = yes
wide symlinks = yes
unix extensions = no

No success. I can't change to symlinked libraries when I'm connecting samba from windows xp client.

@prygme: sounds like your issue is different. Also the bug was about CIFS mounts, which are affected by mount options (-o nounix) and not by smb.conf parameters. Please open a separate bug if you want to report a regression in Lucid.

@joel garbor: the option for symlinks out of the shared directory is called "wide links = yes" (not wide SYMlinks)
on lucid i also had to install some other packages to make it work (like samba-tools smbfs libpam-mount winbind) sorry i don't know which one does the trick (i believe smbfs)

I'm on Ubuntu 10.04, Lucid Lynx.

uname -a
Linux raja 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

follow symlinks = yes
wide symlinks = yes
unix extensions = no

in /etc/samba/smb.conf

Symlinks are not getting followed on the server. My Mac can seem them but can't follow them. (They're not wide, either). I also tried xapient's suggestion of installing samba-tools, smbfs, libpam-mount, and winbind.

Oh, by the way, I did not have this issue in Ubuntu 9.x

@Mason Kramer: Change "wide symlinks" to "wide links" and make sure it's in the [global] section. It's working for me in 10.04:

uname -a
Linux lucid 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux