(Cập nhật điều này, khi tôi giải quyết một số kink)
Trên đây là khó hiểu. Bạn đang nói về một chia sẻ SMB được chia sẻ từ máy chủ linux hoặc máy chủ windows?
Tôi chỉ kiểm tra cái này (tôi có ổ 'C') được gắn trên máy khách linux của tôi.
Tất nhiên trên windows, trong root, tất cả các symlink đều hoạt động. Tuy nhiên trên máy khách linux của tôi, tôi thấy
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/
Tất cả các liên kết giải quyết trên cả Windows (7) và trên Linux. Trước đây, tôi có một số màu đỏ, cho biết không thể giải quyết được liên kết tượng trưng, nhưng ngoài việc đảm bảo các đường dẫn hoạt động từ cả Windows và Linux, là một số nhất định (một số tôi đã thử các liên kết tương đối, mà tôi đã nhầm lẫn), vấn đề chính là những vấn đề được chỉ ra là bị hỏng là "JUNCTION", chứ không phải "SYMLINKD" (như đã lưu ý trong 'cmd.exe' và thực hiện một 'thư mục' ở gốc của chia sẻ đó.
Bây giờ tôi biết, nói chung, có sự khác biệt trong triển khai, NHƯNG, các triển khai symlink [d] tương thích (đường dẫn được cung cấp là chính xác. Tức là trên Windows, "cmd, dir" hiển thị:
11/29/2012 07:14 PM <SYMLINKD> Home [C:\Users]
Trên Windows trong cygwin, nó hiển thị:
lrwxrwxrwx 1 6 Nov 29 2012 Home -> /Users/
và trên linux sử dụng máy khách CIFS, nó hiển thị:
l--------- 1 0 Nov 29 2012 Home -> /??/C:/Users/
Windows lưu trữ các liên kết tượng trưng của nó (được tạo bằng mklink hoặc mklink / d cho các thư mục) theo cùng định dạng với đường dẫn windows.
Linux linh hoạt hơn nhiều so với những gì nó cho phép và bạn có thể tạo một thư mục có tên "/ ??" trong "/", theo đó, tôi cần 2 mục:
lrwxrwxrwx 1 10 Feb 28 15:43 C: -> ../Athenae/
drwxrwx---+ 3 44 Feb 28 16:13 UNC/
Đầu tiên là một symlink linux thông thường, sau đó thứ hai là một dir.
Athenae là máy windows xuất ổ đĩa 'root (C :)' sang máy khách linux; trên máy khách linux được gắn tại / Athenae. Vì vậy, bất kỳ tham chiếu nào đến C: từ cửa sổ symlink sẽ quay trở lại thư mục gốc của chia sẻ được gắn trên linux.
Trong UNC, tôi đặt các tên máy chủ mà tôi muốn tạo ra (tất cả cùng tên cho máy chủ 1 linux, nhưng nó được gọi ở các vị trí khác nhau vì nó cũng là bộ điều khiển miền):
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/
(trong khi trường hợp không quan trọng trên windows, thì nó cũng có trên linux, do đó, viết hoa xen kẽ tên máy chủ và tên miền, cả hai đều trỏ đến 1 thư mục thực trong đó tôi đặt các liên kết tượng trưng để giải quyết). trong đó tôi LƯU Ý: một số chia sẻ đó là 'NGƯỜI DÙNG' cụ thể và vì bạn không thể đặt 'tên biến' trong một liên kết tượng trưng (nhưng ...?) như : ln -s '$HOME/Documents' Documents, tôi phải trỏ liên kết Tài liệu tới một vị trí cố định - - không phải là vấn đề trong trường hợp của tôi vì tôi là người duy nhất đang cố gắng giải quyết các liên kết tượng trưng của Windows Share được gắn kết này với máy khách CIFS linux).
(Rất nhiều cuộc nói chuyện cũ về các vấn đề liên kết tôi đã có trước đó, đã bị loại bỏ).
Nếu bạn đang cài đặt từ một máy chủ dựa trên linux w / samba, thì đó là các quy tắc rất khác nhau - nhưng samba có thể theo các liên kết linux nếu nó được cấu hình với các phần mở rộng linux, widelinks và "client Managed links links = yes", mặc dù param sau đó đã " sai " được đổi tên thành:
allow insecure wide links = yes
bởi vì hầu hết các quản trị viên Windows không cho phép người dùng đăng nhập vào máy chủ của họ và do đó coi đó là một lỗ hổng trong chính sách bảo mật của họ. Đối với những quản trị viên cửa sổ sử dụng quyền và ACL để kiểm soát quyền truy cập và có 'người dùng đáng tin cậy' (về cơ bản là tôi và bạn cùng nhà), đó không phải là một lỗ hổng, nhưng là một điều may mắn.
Tất cả phụ thuộc vào 'chính sách bảo mật' của bạn ... ;-)
Hy vọng điều này thêm một số sự rõ ràng cho các chia sẻ được chia sẻ từ Windows và được truy cập thông qua linux (hoặc windows) ...
ps không có ý nghĩa tấn công hay ngụ ý! ;-)
---- các cifs-utils mới nhất dường như hiển thị tất cả các liên kết tượng trưng có trên windows hoạt động cũng như bất kỳ symlink linux nào (tức là nếu mục tiêu tồn tại, chúng hoạt động):
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/
Tất cả các liên kết này 'giải quyết' và chỉ ra những gì chúng được cho là ... Trên hộp linux.
Bây giờ, chúng theo cách khác - các liên kết linux - chúng không được xem là 'symlink' trên máy khách windows - nhưng máy khách linux có thể thấy các liên kết cửa sổ cho những gì chúng là và chọn sao chép chúng hoặc theo dõi chúng. Đây là sử dụng cifs-utils-6.4-3.2.2.x86_64.
Tôi thấy điều này thật tuyệt vời ... Tôi sẽ có thể thực hiện sao lưu 'tar' hoàn chỉnh từ linux (nếu tôi làm cho ánh xạ SID-> UID hoạt động, nó thậm chí sẽ có quyền sở hữu chính xác và ACL) ....