Ubuntu + latest samba version, symlinks no longer work on share mounted in windows

Question

I just apt-getted (apt-got?) the latest software for my Ubuntu 9.10 linux box, and I noticed that samba was the included in the update.

After the install, the symlinks in my home directory no longer work when mounted as a drive in my linux box. They worked literally seconds before I did the update. All my normal directories work just fine. Viewing the directory listing on the command line, all the files, dirs & links have the exact same permissions, yet this is the error I get:

Location is not available
L:\LinkDir is not accessible.
Access is denied.

I looked on the forums, and i saw this option for the smb.conf

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

I put those in, but they had no effect. Has anyone had this problem yet?

Answer 1

There was a recent security issue in Samba (Feb 5 2010), a claimed zero-day exploit that exploited an insecure default configuration. According to an Ubuntu Forums post on the topic, the "wide links" option now defaults to no.

Apparently the option's name was changed since those earlier instructions you found.

Adding this to the global section of your smb.conf file should fix the issue:

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

After saving smb.conf, be sure you restart Samba:

sudo /etc/init.d/samba restart

Answer 2

This helped me too although I didn't think it would. I have two Samba shares on mu Ubuntu. In both shares I use symlinks but in one disrectory (shared) the symlinks were working but in another disrectory (also shared) the weren't.

I had no problems following the links on the linux but on the Win it wouldn't work.

I could even use two puTTy windows next to each other, one in my /data directory and one in my /data2 directory and issue the same command: ln -s /data3/Mydata.

The Mydata directory would appear in both my mapped drives on the Win box but in one case it would work but in the other I'd get an "Access denied" error.

The "unix extensions = no" did the trick but I don't know why...

Answer 3

NB : already posted this to answer another question, but when posting the link only, my (very short !) reply has been converted into a comment to this initial question (see above), and turned slightly invisible. So, for visibility, here's the full answer again :

To allow Samba clients to follow symlinks outside of the shared path, all you need in the Samba configuration is :

[global]
allow insecure wide links = yes
unix extensions = no

[myShare]
wide links = yes

(in addition to the Samba shares definitions themselves, of course). This is -theoretically- enough for *nix clients.

NB : The "follow symlinks" directive is not necessary as it defaults to "yes"

As for Windows clients, 1 setting is still missing to let them follow such links. To do so :

1. open a Windows shell having Administrator privileges

2. run :

   fsutil behavior set SymlinkEvaluation L2L:1 R2R:1 L2R:1 R2L:1
   

3. reboot to reload settings

NB : the same result can be obtaind by editing the Windows registry. See links below

sources :

• https://nim-labs.com/enabling-windows-recognize-symbolic-links/
• https://stackoverflow.com/questions/229643/how-do-i-overcome-the-the-symbolic-link-cannot-be-followed-because-its-type-is#answer-230047

Answer 4

I've had the same problem, but for me, putting "unix extensions = no" into the [global] section of smb.conf did fix the issue. It is important that you put it into the unix extension flag into global section (valid for all shares), as this is parsed before Samba knows which share the user connects to. The Wide links option can go into the share to which is applies.

Just a remark for those gotten bitten by this behavior, and want to avoid similar occurrences in the future: The samba team doesn't read distribution's bug trackers, but they do have their own list:

[e-mail]

The samba team lives under the impression that only a tiny minority of people are affected by this bug, and they can only be convinced otherwise if more people make their voices heard. So if you care, drop a note to [e-mail]

Thanks,

Alain