105

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.

mit
  • 1,443

5 Answers5

152

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

Pete
  • 274
Mahesh K.
  • 1,646
  • See also the explanation at the end of the question above why this is a good solution. – mit Jun 18 '14 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 – Frank N Sep 26 '16 at 07:24
  • 3
    does [share] mean [<share_name>]? – Necktwi Aug 04 '18 at 08:24
  • @neckTwi - That's what I assumed, and it worked for me. – Geoff Aug 13 '18 at 21:47
  • @Geoff That didn't work for me! switched to sshfs – Necktwi Aug 14 '18 at 02:29
  • This worked for me. And don't forget to restart smb and reconnect drive. – FractalSpace Oct 23 '18 at 18:44
  • @neckTwi sshfs sucks – FractalSpace Oct 23 '18 at 18:45
  • Is the difference between follow symlinks and wide links that the former disables ALL symlinks for the client, but the latter only disables symlinks that lead outside of the share? – Levi Uzodike May 06 '21 at 21:41
  • Interesting, allow insecure wide links must be set as a global option. If I add it in the [share] section then it won't work ... – daisy May 09 '21 at 06:56
  • 1
    The parameter allow insecure wide links can be really insecure because it doesn't check that unix extensions = no. Symbolic links can be then created remotely from a Unix machine by Samba if unix extensions are enambled on both machines which is detault.

    "It is not recommended to enable this option unless you fully understand the implications of allowing the server to follow symbolic links created by UNIX clients. For most normal Samba configurations this would be considered a security hole and setting this parameter is not recommended." (quoted from man smb.conf)

    – hynekcer Nov 19 '21 at 12:03
  • These wide links means that samba client can add link to any file of any user on Linux server and read it if it is having permission Access: (05) or how is that exactly regarding permissions and rights? If i set my share to "read only = yes" then i will prevent any symbolic link addition by the client right? – 16851556 Feb 16 '22 at 15:41
  • 1
    I confirm that allow insecure wide links = yes is needed for Ubuntu 22.04 under global, in addition to wide links = yes for the share. – Johannes Overmann Jun 27 '22 at 06:46
22

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
13

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
Michael Mrozek
  • 93,103
  • 40
  • 240
  • 233
Qiqi
  • 286
  • Qiqi's answer agrees with this one: http://superuser.com/questions/128716/ubuntu-latest-samba-version-symlinks-no-longer-work-on-share-mounted-in-window – Janus Jan 03 '11 at 04:49
  • Yes, this definitely fixes the issue in my environment. – TML Jul 28 '11 at 16:49
9

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 :

Httqm
  • 1,136
0

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
palswim
  • 5,167