SMB 공유에 절대 경로가 있는 심볼릭 링크가 있는 경우 /share/latest/dir -> /share/data/201407Windows 클라이언트는 문제 없이 링크를 통해 파일에 액세스할 수 있습니다.
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 클라이언트에 대한 특별 지원을 비활성화합니다. 만약에유닉스 확장매개변수가 "no"로 설정된 경우 Windows 및 Linux 클라이언트는 동일한 결과를 얻습니다.
smbserver:~# vi /etc/samba/smb.conf
[global]
unix extensions = No
smbserver:~# restart smbd
3) SAMBA 클라이언트에서 UNIX에 대한 특별 지원을 비활성화합니다. 사용명사공유 마운트 시 옵션. nounix 옵션은 UNIX ACL, 노드 ID 및 잠금이 사용되지 않도록 CIFS Unix 확장을 비활성화합니다.
client:~$ sudo mount -t cifs -o nounix //smbserver/share /mnt
답변2
(내가 이것을 업데이트했기 때문에도끼를 묻어라몇 가지 문제)
위의 내용은 혼란스럽습니다. Linux 서버 또는 Windows 서버에서 공유되는 SMB 공유를 언급하고 있습니까?
방금 내 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"("cmd.exe" 및 공유 루트에서 "dir" 실행에 설명된 대로)가 아니라 "JUNCTION"입니다.
이제 나는 일반적으로 구현에 차이가 있다는 것을 알고 있습니다. 그러나 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는 "루트(C:)" 드라이브를 /Athenae에 설치된 Linux 클라이언트로 내보내는 Windows 시스템입니다. 따라서 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 확장, 와이드링크 및 "클라이언트 관리형 와이드 링크 = 예"가 구성된 경우 Samba는 Linux 심볼릭 링크, 매개변수 세트를 존중할 수 있습니다(나중 매개변수는 다음과 같습니다). "틀리게” 이름이 다음으로 변경되었습니다.
allow insecure wide links = yes
대부분의 Windows 관리자는 사용자가 서버에 로그인하는 것을 허용하지 않기 때문에 이는 보안 정책의 결함으로 간주됩니다. 액세스를 제어하기 위해 권한과 ACL을 사용하고 "신뢰할 수 있는 사용자"(기본적으로 나와 내 룸메이트)가 있는 Windows 관리자에게 이는 결함이 아니라 축복입니다.
모든 것은 "보안 정책"에 따라 다릅니다... ;-)
이로 인해 Windows에서 공유하고 Linux(또는 Windows)를 통해 액세스하는 것이 좀 더 명확해지기를 바랍니다.
p.s. 어떠한 의도나 암시도 없습니다! ;-)
---- 최신 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 마운트의 정규화된 파일 경로에 대한 원시 링크는 로컬 시스템에서 로컬 경로로 해석되며, 뒤따르는 로컬 경로가 서버측을 위한 것이 아닌 경우 실제 혼란이 발생할 수 있습니다.즉, 서버가 링크를 해결한다고 가정하지 마십시오! 그렇지 않습니다!귀하의 상황에 대해 이것을 확인하지는 않았지만 귀하가 받은 다른 조언을 고려하면 그럴 것 같습니다.