Yrurtj

This is Ubuntu server 10.04 64 and samba 3.4.7.

I have a shared directory /home/mit/share and another one /home/temp that I link into the shared one:

ln -s /home/temp /home/mit/share/temp

But on windows, after using internet, I cannot open S:/temp, but on Linux it is possible to access /home/mit/share/temp like expected.

This works if I link directories inside /home/mit/share/temp, so I guess samba is restricting to jump with a link outside/above the shared directory.

EDIT:

See also this question titled Ubuntu + latest samba version, symlinks no longer work on share mounted in Windows.

It seems best to put unix extensions = no into the global section and follow symlinks = yes and wide links = yes only into the shares section, where you really need it.

The unix extension flag has to live in the global section and not in the individual shares sections. But for security reasons it is better to use the other options only where you need it, and not globally.

Edit smb.conf

[global]

unix extensions = no



[share]

follow symlinks = yes

wide links = yes

Note: If you're using a newer version of samba the following may work for you instead:

[global]

allow insecure wide links = yes



[share]

follow symlinks = yes

wide links = yes

documentation on follow symlinks and wide links flags: https://www.samba.org/samba/docs/using_samba/ch08.html#samba2-CHP-8-TABLE-1

Greetings, I've tried putting this into configuration to fix symlinks for windows for my setup , but I am not sure if it will affect windows client, otherwise it follows symlinks when I connect to this box.

[global]                                                                        

unix extensions = no

Alternatively to the other answers, to keep the unix extensions enabled, it is possible to use:

[global]

allow insecure wide links = yes



[share]

follow symlinks = yes

wide links = yes

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

You may need to address more than just the Samba configuration file if you are running AppArmor.

You do need the following directives in your smb.conf:

follow symlinks = yes

wide links = yes

unix extensions = no

# No need for "allow insecure wide links" unless you want "unix extensions = yes"

But, AppArmor blocks access to parts of the file system according to its own ruleset semantics. So, if your symlink within Samba pointed to a location which AppArmor would block, Samba would deny access.

On my system, Samba updates AppArmor profiles on the service start/stop, so I could change an AppArmor profile, but risk Samba or another program overwriting it. Instead, I decided to create an inaccessible share in Samba referencing the location which contained the symlink target I wanted to access (still in smb.conf):

# The following is a hack for AppArmor to allow the path

[share1 for AppArmor] # Or whichever name you choose

    browseable = no

    path = /home # Point to directory or parent directory of the location to access

    read only = yes

    guest ok = no

    valid users = none