SAMBA共有の絶対シンボリックリンクの直後にCIFSマウントが続くのはなぜですか？
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マウントでシンボリックリンクを追跡するにはどうすればよいですか？
問題は、SAMBAサーバーがunix（cifs）クライアントの特別なサポートを組み込んでいることです。 Linuxホストでmount -t cifsを使用すると、すべてのシンボリックリンクがそのまま（cifsクライアント）に渡されます。
ls /mnt/share/latest/dir/ -l
/mnt/share/latest/dir/ -> /opt/share/data/201407
この機能は嫌いかもしれませんが、これは設計上の決定であり、長所があります。バグではなく、機能です！ :)しかし、解決策があります：
1）共有ディレクトリの絶対シンボリックリンクを相対シンボリックリンクに置き換えます。
smbserver:~> ln -s ../../data/201407 /opt/share/latest/dir
2）SAMBAサーバー上のUNIXクライアントの特別なサポートを無効にします。 nix extensionsパラメータを「no」に設定すると、WindowsクライアントとLinuxクライアントの両方で同じ結果が得られます。
smbserver:~# vi /etc/samba/smb.conf
[global]
unix extensions = No
smbserver:~# restart smbd
3）SAMBAクライアントでUNIXの特別なサポートを無効にします。共有をマウントするときにnounixオプションを使用します。 nounixオプションはCIFS Unix拡張機能を無効にするため、UNIX ACL、ノードID、ロックは使用されません。
client:~$ Sudo mount -t cifs -o nounix //smbserver/share /mnt
（これを更新したので、私はいくつかのねじれを修正しました
上記は紛らわしいです。 SMB共有はLinuxサーバーまたはWindowsサーバーから共有されていますか？
私はこれをLinuxクライアントにマウントして確認しました（「C」ドライブを持っています）。
もちろん、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の両方からパスが機能することを確認することに加えて、（いくつか私がめちゃくちゃにした相対リンクを試しました）、主な問題は、「SYMLINKD」ではなく「JUNCTION」であり、その共有のルートで「dir」を実行していることです。
今、私は一般的に、実装に違いがあることを知っていますが、symlink [d]の実装はcompatibleです（パスが正しい場合。つまり、Windowsでは、「cmd、dir」は次のように表示されます：
11/29/2012 07:14 PM <SYMLINKD> Home [C:\Users]
CygwinのWindowsでは、次のように表示されます。
lrwxrwxrwx 1 6 Nov 29 2012 Home -> /Users/
linuxでCIFSクライアントを使用すると、次のように表示されます。
l--------- 1 0 Nov 29 2012 Home -> /??/C:/Users/
Windowsは、シンボリックリンク（ディレクトリのmklinkまたはmklink/dで作成）を、windows-pathと同じ形式で保存します。
Linuxはそれが許す範囲ではるかに用途が広く、 "/ ??"と呼ばれるディレクトリを作成できます。 "/"の下には、2つのエントリが必要でした。
lrwxrwxrwx 1 10 Feb 28 15:43 C: -> ../Athenae/
drwxrwx---+ 3 44 Feb 28 16:13 UNC/
1つ目は通常のLinuxシンボリックリンクで、2つ目はディレクトリです。
Athenaeは、「root（C :)」ドライブをLinuxクライアントにエクスポートするWindowsマシンです。/AthenaeにマウントされているLinuxクライアント上。したがって、WindowsのC：からの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、ドキュメントのシンボリックリンクを固定の場所に向ける必要がありました-私の場合、このマウントされたWindows共有のシンボリックリンクをLinux CIFSクライアントで解決しようとしているのは私だけなので、問題ではありません。
（私が以前に持っていたリンクの問題についての多くの古い話は省略されました）。
Sambaを使用するLinuxベースのサーバーからマウントする場合は、ルールが大きく異なりますが、Sambaは、Linux拡張、ワイドリンク、および「クライアント管理のワイドリンク=はい」、パラメーターセット（ただし、後のパラメータは「incorrectly」に改名されました：
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が必要です）。..