(atualizei isto, enquanto eu resolvi algumas das torções)
O acima é confuso. Você está falando de um compartilhamento SMB compartilhado a partir de um servidor linux ou de um servidor Windows?
Eu estava apenas verificando isso (eu tenho o meu 'C'-drive) montado no meu cliente Linux.
Claro que no Windows, na raiz, todos os links simbólicos funcionam. No entanto no meu cliente linux eu vejo
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/
Todos os links são resolvidos no Windows (7) e no Linux.
Antes, eu tinha algumas em vermelho, indicando que o link simbólico não poderia ser resolvido, mas além de ter certeza de que os caminhos funcionavam tanto do Windows quanto do Linux, é um dado (alguns eu tentei links relativos, o que eu errei) O principal problema foi que os que indicaram quebrado eram "JUNCTION" s, não "SYMLINKD" (como observado em 'cmd.exe' e fazendo um 'dir' na raiz desse compartilhamento.
Agora eu sei, em geral, existem diferenças na implementação, MAS,
as implementações do symlink [d] são compatíveis (os caminhos fornecidos são
corrigir. Ou seja No Windows, "cmd, dir" mostra:
11/29/2012 07:14 PM <SYMLINKD> Home [C:\Users]
No Windows no cygwin, mostra:
lrwxrwxrwx 1 6 Nov 29 2012 Home -> /Users/
e no linux usando o cliente CIFS, mostra:
l--------- 1 0 Nov 29 2012 Home -> /??/C:/Users/
O Windows armazena seus links simbólicos (feitos com mklink ou mklink / d para diretórios) no mesmo formato com um caminho do Windows.
O Linux é muito mais versátil no que ele permite, e você pode criar um diretório
chamado "/??" em "/", abaixo disso, eu precisava de 2 entradas:
lrwxrwxrwx 1 10 Feb 28 15:43 C: -> ../Athenae/
drwxrwx---+ 3 44 Feb 28 16:13 UNC/
O primeiro é um link simbólico normal do Linux, depois o segundo é um diretório.
Athenae é a máquina windows exportando sua unidade 'root (C :)' para o cliente linux; no cliente linux montado em / Athenae.
Assim, qualquer referência a C: a partir do link simbólico do Windows apontará de volta para a raiz
do compartilhamento montado no linux.
Sob UNC eu coloquei os nomes de host que eu queria fazer funcionar (tudo a mesma coisa
nome para o servidor 1 linux, mas é referido de forma diferente em
lugares diferentes porque também é um controlador de domínio):
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/
(embora o case não importe no windows, ele faz no linux, portanto, uma alternativa
capitalização do nome do host e do nome do domínio, ambos apontam para um diretório real onde eu coloquei os links simbólicos para serem resolvidos). onde eu
NOTA: alguns desses compartilhamentos são específicos de 'USER', e como você não pode colocar 'nome de variável' em um link simbólico (ainda ...?) Como: ln -s '$HOME/Documents' Documents , eu tive que apontar o link simbólico de Documentos para um local fixo - não é um problema no meu caso, já que eu sou o único tentando resolver os links simbólicos deste Windows Share montado com o cliente CIFS linux).
(Alot da velha conversa sobre os problemas de link que eu tive anteriormente, elidiu).
Se você está montando a partir de um servidor baseado em linux w / samba, são regras muito diferentes - mas o samba pode seguir linux symlinks se estiver configurado com extensões linux, widelinks e o "client managed wide links = yes", param set (embora o último parâmetro tenha sido " incorretamente " renomeado para:
allow insecure wide links = yes
porque a maioria dos administradores do Windows não permite que os usuários façam login no servidor e, portanto, o consideram uma falha em sua política de segurança. Para aqueles administradores de janelas que usam permissões e ACLs para controlar o acesso e ter 'usuários confiáveis' (eu e colegas de casa, basicamente) não foi uma falha, mas uma bênção.
Tudo depende da sua 'política de segurança' ...; -)
Espero que isso adicione alguma clareza para os compartilhamentos que estão sendo compartilhados do Windows e acessados via linux (ou windows) ...
p.s. sem ataques significados ou implícitos! ; -)
---- o último cifs-utils parece mostrar todos os symlinks presentes no windows funcionando bem como qualquer link simbólico do linux (ou seja, se o destino existir, eles funcionam):
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/
Todos esses links 'resolvem' e apontam para o que eles devem ...
Na caixa linux.
Agora, eles têm outro caminho - linux symlinks - eles não são vistos como 'links simbólicos' em um cliente windows - mas um cliente linux pode ver links simbólicos do Windows para o que eles são e optar por copiá-los ou segui-los .
Isso está usando o cifs-utils-6.4-3.2.2.x86_64.
Eu acho isso incrível ... Eu deveria ser capaz de fazer um backup completo 'tar'
linux (se eu obtiver o mapeamento SID- > UID funcionando, ele deve ter propriedade e ACL corretos) ....