如果 SMB 共享具有带绝对路径的符号链接/share/latest/dir -> /share/data/201407，则 Windows 客户端可以通过链接访问文件，不会出现任何问题。
dir \\smbserver\share\latest\dir\
Directory: \\smbserver\share\latest\dir\
file a ...
但是，unix 客户端在同一共享的 cifs 挂载上会出现错误。
ls /mnt/share/latest/dir/
/mnt/share/latest/dir/ : No such file or directory
为什么 Samba 挂载不遵循符号链接？如何让 CIFS 挂载遵循符号链接？
答案1
问题是 SAMBA 服务器内置了对 unix (cifs) 客户端的特殊支持。当您在 Linux 主机上使用 mount -t cifs 时，所有符号链接都会按原样传递给您（cifs 客户端）。
ls /mnt/share/latest/dir/ -l
/mnt/share/latest/dir/ -> /opt/share/data/201407
您可能不喜欢这个功能，但这是一个有其优点的设计决策，ea 不是一个错误，它是一个功能！ :) 但有解决方案：
1) 将共享目录中的绝对符号链接替换为相对符号链接。
smbserver:~> ln -s ../../data/201407 /opt/share/latest/dir
2) 禁用 SAMBA 服务器上对 UNIX 客户端的特殊支持。如果UNIX 扩展参数设置为“no”，那么 Windows 和 Linux 客户端将得到相同的结果。
smbserver:~# vi /etc/samba/smb.conf
[global]
unix extensions = No
smbserver:~# restart smbd
3) 在 SAMBA 客户端上禁用对 UNIX 的特殊支持。使用名词安装共享时的选项。 nounix 选项禁用 CIFS Unix 扩展，以便不使用 UNIX ACL、节点 ID 和锁。
client:~$ sudo mount -t cifs -o nounix //smbserver/share /mnt
答案2
（更新了这个，因为我冰释前嫌一些问题）
上面的内容很混乱。您指的是从 Linux 服务器还是 Windows 服务器共享的 SMB 共享？
我刚刚检查了这个（我有我的“C”驱动器）安装在我的 Linux 客户端上。
当然，在 Windows 上，在根目录中，所有符号链接都有效。但是在我的 Linux 客户端上我看到
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/
所有链接均可在 Windows(7) 和 Linux 上解析。之前，我有一些红色，表明符号链接无法解析，但除了确保路径在 Windows 和 Linux 上都有效之外，是给定的（有些我尝试过相对链接，但我搞砸了），主要问题是那些表明损坏的是“JUNCTION”，而不是“SYMLINKD”（如“cmd.exe”中所述并在该共享的根目录下执行“dir”）。
现在我知道，一般来说，实现存在差异，但是 symlink[d] 实现是兼容的（前提是路径正确。即在 Windows 上，“cmd, dir”显示：
11/29/2012 07:14 PM <SYMLINKD> Home [C:\Users]
在 Windows 上的 cygwin 中，它显示：
lrwxrwxrwx 1 6 Nov 29 2012 Home -> /Users/
在使用 CIFS 客户端的 Linux 上，它显示：
l--------- 1 0 Nov 29 2012 Home -> /??/C:/Users/
Windows 以与 windows 路径相同的格式存储其符号链接（使用 mklink 或 mklink /d 对于目录创建）。
Linux 在其允许的方面更加通用，您可以创建一个名为“/??”的目录。在“/”下，我需要两个条目：
lrwxrwxrwx 1 10 Feb 28 15:43 C: -> ../Athenae/
drwxrwx---+ 3 44 Feb 28 16:13 UNC/
第一个是常规的 Linux 符号链接，第二个是目录。
Athenae 是将其“root(C:)”驱动器导出到 Linux 客户端的 Windows 计算机；在安装在 /Athenae 的 Linux 客户端上。因此，从 Windows 符号链接对 C: 的任何引用都将指向 Linux 上已安装共享的根目录。
在 UNC 下，我放置了我想要使用的主机名（对于 1 个 Linux 服务器来说，它们的名称都相同，但在不同的地方它的引用方式不同，因为它也是一个域控制器）：
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/
（虽然大小写在 Windows 上并不重要，但在 Linux 上却很重要，因此主机名和域名的大小写不同，都指向 1 个真实目录，我在其中放置要解析的符号链接）。我注意到：其中一些共享是特定于“用户”的，并且由于您不能将“变量名称”放入符号链接中（还...？），例如：ln -s '$HOME/Documents' Documents，我必须将文档符号链接指向固定位置 - - 对我来说这不是问题，因为我是唯一一个尝试用 Linux CIFS 客户端解析此已安装 Windows 共享的符号链接的人）。
（很多关于我之前遇到的链接问题的旧讨论被省略了）。
如果您从基于 linux 的服务器使用 samba 进行挂载，则规则非常不同 - 但如果配置了 linux 扩展、widelinks 和“客户端管理的 Wide links = yes”，则 samba 可以遵循 linux 符号链接，参数集（尽管后来的参数是“不正确地” 重命名为：
allow insecure wide links = yes
因为大多数 Windows 管理员不允许用户登录他们的服务器，因此将其视为安全策略中的缺陷。对于那些使用权限和 ACL 来控制访问并拥有“可信用户”（基本上是我和室友）的 Windows 管理员来说，这不是一个缺陷，而是一个祝福。
一切都取决于您的“安全策略”...;-)
希望这可以让从 Windows 共享并通过 Linux（或 Windows）访问的共享更加清晰......
ps 没有任何攻击的意思或暗示！ ;-)
---- 最新的 cifs-utils 似乎显示了 Windows 上存在的所有符号链接以及任何 Linux 符号链接（即如果目标存在，它们就可以工作）：
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/
所有这些链接都会“解析”并指向它们应该做的事情......在linux机器上。
现在，它们以另一种方式 - Linux 符号链接 - 它们在 Windows 客户端上不被视为“符号链接” - 但 Linux 客户端可以看到 Windows 符号链接的内容，并选择复制它们或遵循它们。这是使用 cifs-utils-6.4-3.2.2.x86_64。
我发现这太神奇了...我应该能够从 linux 进行完整的“tar”备份（如果我让 SID->UID 映射工作，它甚至应该具有正确的所有权和 ACL）...
答案3
我真的对这个问题感到困惑：为什么不使用 NFS（另外）呢？我愿意并且非常高兴。我的 Windows 客户端获得 Samba，我的 'nix 客户端获得 NFS，一切都很高兴。
但是，如果您这样做，链接仍然可能会出现问题。 ...来自 NFS 挂载的指向完全限定文件路径的原始链接将被本地计算机解释为本地路径，如果它遵循的本地路径不是该路径，则可能会出现真正的混乱旨在服务器端。也就是说，不要假设服务器解析了链接！它不是！我还没有针对你的情况证实这一点，但考虑到你得到的其他建议，这似乎很可能。