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?
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
(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)....
I'm truly puzzled by the question: Why not use NFS instead (in addition)? I do and am very happy. My Windows clients get Samba and my 'nix clients get NFS and all are happy.
However, if you do this, you can still have issues with links. ... An original link from an NFS mount that points to a fully qualified file path WILL get interpreted by the local machine as a local path and real confusion can arise if there is a local path for it to follow that wasn't the one intended on the server side. That is, do not assume that the server resolves the link! It does not! I haven't confirmed this for your situation, but it seems likely given the other advice you were given.
