7

If an SMB share has a symlink with an absolute path /share/latest/dir -> /share/data/201407 then Windows clients can access files by link with no problem.

dir \\smbserver\share\latest\dir\
Directory: \\smbserver\share\latest\dir\
file a ...

However unix clients get an error on the cifs mount of same share.

ls /mnt/share/latest/dir/ 
/mnt/share/latest/dir/ : No such file or directory

Why does Samba mount not follow the symlink? How can I get a CIFS mount to follow symbolic links?

8

The issue is SAMBA server has build in special support for unix (cifs) clients. When you use mount -t cifs on your linux host all symlinks are passed to you (cifs client) as is.

ls /mnt/share/latest/dir/ -l 
/mnt/share/latest/dir/ -> /opt/share/data/201407

You may dislike this functionality but this is a design decision that has its pros, e.a. is not a bug, it is a feature! :) But there are solutions:

1) Replace absolute symlink in shared directory by relative one.

smbserver:~> ln -s ../../data/201407 /opt/share/latest/dir

2) Disable special support for UNIX clients on SAMBA server. If unix extensions parameter set to "no" then both Windows and Linux clients will get same results.

smbserver:~# vi /etc/samba/smb.conf
[global]
unix extensions = No
smbserver:~# restart smbd

3) Disable special support for UNIX on your SAMBA client. Use nounix option when mountinig share. The nounix option disables CIFS Unix Extensions so that no UNIX ACL, node ids and lock will be used.

client:~$ sudo mount -t cifs -o nounix //smbserver/share /mnt
0

(Updated this, as I ironed out some of the kinks)

The above is confusing. Are you talking an SMB share shared from a linux server or a windows server?

I was just checking this out (I have my 'C'-drive) mounted on my linux client.

Of course on windows, in the root, all the symlinks work. However on my linux client I see

    s# ll /athenae
total 100663718
drwxr-xr-x 2            0 Sep  9 12:53 $RECYCLE.BIN/
-rwxr-xr-x 1        53342 Dec  4  2011 Cygwin-Terminal.ico*
-rwxr-xr-x 1           51 Dec 10  2009 Cygwin.bat*
-rwxr-xr-x 1       157097 Dec  4  2011 Cygwin.ico*
l--------- 1            0 Jul 16  2013 D -> /??/UNC/Ishtar/Documents
drwxr-xr-x 2            0 Jul 13  2009 Documents and Settings/
drwxr-xr-x 2            0 May  4  2014 Drivers/
drwxr-xr-x 2            0 Jan 16 03:21 Fraps/
l--------- 1            0 Nov 29  2012 Home -> /??/C:/Users/
dr-xr-xr-x 2            0 Aug 28  2013 MSOCache/
drwxr-xr-x 2            0 Sep 18 16:01 PortableApps/
drwxr-xr-x 2            0 Nov  6 19:45 Prog/
drwxr-xr-x 2            0 Jan 17 15:35 Program Files/
drwxr-xr-x 2            0 Jan 17 16:36 Program Files (x86)/
drwxr-xr-x 2            0 Dec 30 14:24 ProgramData/
drwxr-xr-x 2            0 Aug 28  2013 Python27/
drwxr-xr-x 2            0 Aug 28  2013 RAMDISK/
drwxr-xr-x 2            0 Nov  2  2013 Recovery/
drwxr-xr-x 2            0 Oct 11 08:24 Recycled/
l--------- 1            0 Mar 28  2013 Share -> /??/UNC/Bliss/Share
drwxr-xr-x 2            0 Jul  6  2011 Symbols/
drwxr-xr-x 2            0 Jan 20 22:13 System Volume Information/
drwxr-xr-x 2            0 Sep  9 17:44 Users/
drwxr-xr-x 2            0 Jan 12  2014 Win/
drwxr-xr-x 2            0 Jan 17 16:36 Windows/
l--------- 1            0 Mar 21  2014 bin -> /??/C:/windows/system32/cygwin/bin  ## (note, link in W/S32/Cyg/bin points to 64-bit cyg)
-rwxr-xr-x 1           27 Apr 19  2011 boot*
drwxr-xr-x 2            0 Jul  2  2010 boot.d/
-rwxr-xr-x 1           90 Apr 19  2011 boot.ini*
drwxr-xr-x 2            0 Jan 12  2014 cygcommon/
drwxr-xr-x 2            0 Oct  8 17:06 cygwin/
drwxr-xr-x 2            0 Jan  9 20:01 cygwin64/
drwxr-xr-x 2            0 Nov 23 03:34 dev/
drwxr-xr-x 2            0 May 17  2014 devv-/
l--------- 1            0 Apr 11  2014 etc
-rwxr-xr-x 1       208876 Feb 17  2009 grldr*
drwxr-xr-x 2            0 Oct 12 12:58 inetpub/
l--------- 1            0 Jan 13  2014 lib
l--------- 1            0 Dec 16  2009 m -> /??/UNC/Bliss/Music
drwxr-xr-x 2            0 Jun 10  2012 mnt/
drwxr-xr-x 2            0 Jan 12  2014 opt/
l--------- 1            0 Jul 12  2010 p -> /??/UNC/Bliss/Pictures
-rwxr-xr-x 1 103079215104 Jan 10 21:21 pagefile.sys*
drwxr-xr-x 2            0 Jan 23  2014 proc/
l--------- 1            0 Apr 21  2013 prog64 -> Program Files/
-rwxr-xr-x 1         1372 Oct 12 01:37 pulseaudio.exe.stackdump*
l--------- 1            0 Jan 13  2014 sbin
l--------- 1            0 Jan 12  2014 temp -> tmp/
drwxr-xr-x 2            0 Jan 20 23:40 tmp/
l--------- 1            0 Jan 13  2014 usr
l--------- 1            0 Jan 13  2014 var
drwxr-xr-x 2            0 Aug 28  2013 windowsearch/

All of the links resolve on both Windows(7) and on Linux. Before, I had some in red, indicating the symlink couldn't be resolved, but in addition to making sure the paths worked from both Windows and Linux, is a given (some I had tried relative links, which I messed up), the main problem was the ones that indicated broken were "JUNCTION"s, not "SYMLINKD" (as noted in 'cmd.exe' and doing a 'dir' at the root of that share.

Now I know, in general, there are differences in implementation, BUT, the symlink[d] implementations are compatible (provided paths are correct. I.e. On Windows, "cmd, dir" shows:

11/29/2012  07:14 PM    <SYMLINKD>     Home [C:\Users]

On Windows in cygwin, it shows:

lrwxrwxrwx   1            6 Nov 29  2012 Home -> /Users/

and on linux using the CIFS client, it shows:

l--------- 1            0 Nov 29  2012 Home -> /??/C:/Users/

Windows stores its symlinks (made with mklink or mklink /d for directories) in the same format with a windows-path.

Linux is far more versatile in what it allows, and you can create a dir called "/??" in "/", under that, I needed 2 entries:

lrwxrwxrwx 1 10 Feb 28 15:43 C: -> ../Athenae/
drwxrwx---+ 3 44 Feb 28 16:13 UNC/

The first is a regular linux symlink, then second is a dir.

Athenae is the windows machine exporting it's 'root(C:)' drive to the linux client; on the linux client that is mounted at /Athenae. So any reference to C: from the windows symlink will point back to the root of the mounted share on linux.

Under UNC I put the host names I wanted to make work (all the same name for the 1 linux server, but it gets referred to differently in different places because it's also a domain controller):

lrwxrwxrwx  1  6 Feb 28 16:12 Bliss -> Ishtar/
drwxrwx---+ 2 61 Feb 28 16:18 Ishtar/
lrwxrwxrwx  1  6 Feb 28 16:13 ishtar -> Ishtar/

(while case doesn't matter on windows, it does on linux, thus an alternate capitalization of the hostname and the domain name, both point to 1 real dir where I put the symlinks to be resolved). where I NOTE: some of those shares are 'USER' specific, and since you can't put 'variable name' in a symlink (yet...?) like: ln -s '$HOME/Documents' Documents, I had to point the Documents symlink to a fixed location -- not a problem in my case as I'm the only one trying to resolve the symlinks of this mounted Windows Share with the linux CIFS client).

(Alot of old talk about the link problems I had earlier, elided).

If you are mounting from a linux-based server w/samba, it's very different rules -- but samba can follow linux symlinks if it is configured with linux extensions, widelinks and the "client managed wide links = yes", param set (though the later param was "incorrectly" renamed to:

allow insecure wide links = yes

because most Windows admins don't allow users to login to their server and thus saw it as a flaw in their security policy. For those windows admins who use permissions and ACLs to control access and have 'trusted users' (me and housemates, basically) it wasn't a flaw, but a blessing.

All depends on your 'security policy'... ;-)

Hope this add some clarity for the shares being shared from Windows and accessed via linux (or windows)...

p.s. no attacks meant or implied! ;-)

---- the latest cifs-utils seems to show all the symlinks present on windows working as well as any linux symlink (i.e. if the target exists, they work):

Ishtar:/athenae> uname -a
Linux Ishtar 3.19.3-Isht-Van #1 SMP PREEMPT Tue Apr 7 21:40:02 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux 
 Ishtar:/athenae>  ll |grep -- '->'|sed 's/^/    /'
 l--------- 1            0 Jul 16  2013 D -> /??/UNC/Ishtar/Documents/
 l--------- 1            0 Feb 28 16:38 M -> /??/UNC/Bliss/Music/
 l--------- 1            0 Feb 28 16:10 P -> /??/UNC/Bliss/Pictures/
 l--------- 1            0 Mar 28  2013 Share -> /??/UNC/Bliss/Share/
 l--------- 1            0 Mar 21  2014 bin -> /??/C:/windows/system32/cygwin/bin/
 l--------- 1            0 Feb 28 15:34 etc -> /??/C:/Windows/System32/cygwin/etc/
 l--------- 1            0 Mar  5 14:32 lib -> /??/C:/Windows/System32/cygwin/lib/
 l--------- 1            0 May 14 07:15 opt -> /??/C:/Windows/System32/cygwin/opt/
 l--------- 1            0 Apr 21  2013 prog64 -> Program Files/
 l--------- 1            0 Mar  5 14:33 sbin -> /??/C:/Windows/System32/cygwin/sbin/
 l--------- 1            0 Jan 12  2014 temp -> tmp/
 l--------- 1            0 Mar  5 14:35 usr -> /??/C:/Windows/System32/cygwin/usr/
 l--------- 1            0 Mar  5 14:35 var -> /??/C:/Windows/System32/cygwin/var/

All of these links 'resolve' and point to what they are supposed to... On the linux box.

Now, they other way around -- linux symlinks -- they aren't seen as 'symlinks' on a windows client -- but a linux client can see windows symlinks for what they are and choose to copy them or follow them. This is using cifs-utils-6.4-3.2.2.x86_64.

I find this amazing... I should be able to do a complete 'tar' backup from linux (if I get the SID->UID mapping working, it should even have correct ownership and ACL's)....

  • Answering your first question. I was presenting a problem when a share is served on Linux box by SAMBA server and clients were both Samba Client Linux and Windows PC. – smile-on Feb 5 '15 at 1:38
  • Your question is different. You host a share on Windows and using Samba client to access it from Linux. I have no experience in such exercise. Note, "file link" on Linux and Windows are totally different things under same name. Do not confuse them. Settings in my post are related to Linux links and I doubt that Samba client supports Windows Links. Read Advanced Disk Shares to find more details. – smile-on Feb 5 '15 at 1:50
  • a file link on linux and windows are very similar. Not sure who told you they were different, but Windows has hard links that are nearly identical in function to the linux ones. The symlinks (mklink on windows, ln -s on linux) also have rather similar functionality. – Astara Feb 5 '15 at 11:25
  • in response to your 1st comment -- if you are on a client that supports CIFS (modern SMB), and you access a remote share, how would you be sure if it was on linux or on windows? You make it sound like they are very different, but the samba team has 'striven', for as close to duplicate functionality as possible. They can identify differently, but samba can also identify as a windows server running an NTFS file system -- so they might appear very similar. – Astara Feb 5 '15 at 11:28
  • Astra, I understand that from your, end user perspective a notion of the link looks similar on both Liniux and Windows. It is CIFS server and client implementations that see the difference. Instead of attacking me, please, read doc on CIFS UNIX extensions as a proof the implementation is different. Again, I don't use Windows as a CIFS server and can't help you in that regards. – smile-on Feb 11 '15 at 21:48

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.