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.


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.

  • Can you try a hardlink instead of a symlink?
    – Falmarri
    Jan 3, 2011 at 3:54

5 Answers 5


Edit smb.conf

unix extensions = no

follow symlinks = yes
wide links = yes

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

allow insecure wide links = yes

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

  • See also the explanation at the end of the question above why this is a good solution.
    – mit
    Jun 18, 2014 at 16:44
  • In case, somebody else struggles with all those commentary obfuscating this rather short file: copy to a backup, and re-create filtered: 1: cp /etc/samba/smb.conf /etc/samba/smb.conf.bak 2: grep -o '^[^#;]*' smb.conf.bak >smb.conf Sep 26, 2016 at 7:24
  • 2
    does [share] mean [<share_name>]?
    – Necktwi
    Aug 4, 2018 at 8:24
  • @neckTwi - That's what I assumed, and it worked for me.
    – Geoff
    Aug 13, 2018 at 21:47
  • @Geoff That didn't work for me! switched to sshfs
    – Necktwi
    Aug 14, 2018 at 2:29

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

allow insecure wide links = yes

follow symlinks = yes
wide links = yes
  • does [share] mean [<share_name>]?
    – Necktwi
    Aug 4, 2018 at 8:23
  • 3
    Yes, it can be any smb.conf section that 'describes a shared resource (known as a “share”)' (quoted from the documentation). It may be also in a special section [homes], where I use it. See the documentation for details. Aug 4, 2018 at 13:05

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.

unix extensions = no

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

allow insecure wide links = yes
unix extensions = no

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 :


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.