Package: smbfs Version: 2:3.2.5-4lenny7 Severity: normal File: /sbin/mount.cifs
This is about the behaviour of symlinks on CIFS shares. If the client is a Windows machine / doesn't support the CIFS extensions, symlinks will be resolved on the server and thus transparent on the client. I. e. if a link goes to a directory it will look just like a regular directory on the client, etc. A side effect is that the symlinks can be configured to point *outside* the scope of the share proper. If however the client *does* support the CIFS extensions, any symlinks on the share will show up as actual symlinks and be resolved by the client in its local context, meaning: Symlinks to absolute paths stop working (they now reference the client's /, not the server's). Fix is to change all affected symlinks to relative ones. Symlinks to relative paths *within* the scope of the share work normally. Symlinks that point *outside* the scope of the share are no longer (meaningfully) possible at all since these can't be resolved on the client. Now why would wou want these "wide symlinks"? To abstract the servers directory structure with multiple mount points and such into a simler and more logical structure to present to clients. Example: I usually make /home itself rather smallish and *link* to larger available storage with differnet characteristics. E.g. each user has a raid1 and a raid5 "directory" which is actually a link to /mnt/raidX/Users/$USER. 2nd example: I run slimserver (a daemon that serves music to networked players) on a kvm VM and I'd like it to access the music on various file servers via CIFS. The plan was to share one directory per server that contains symlinks to the different directories containing music on it. Apparently that's a no-go. I'd have to share a point so far up in the dir tree that it contains all symlink targets - basically /. That's the equivalent of the Windows drive$ share. Ugly. And in the first case it wouldn't even work. It's either that or turn off CIFS extensions entirely, that's not desirable either. Would it be possble to relax CIFS extension conformance at the discretion of the admin so that relative wide links are always resolved server side? Thanks, C. -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages smbfs depends on: ii libc6 2.7-18 GNU C Library: Shared libraries ii libcomerr2 1.41.3-1 common error description library ii libkeyutils1 1.2-9 Linux Key Management Utilities (li ii libkrb53 1.6.dfsg.4~beta1-5lenny1 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.11-1 OpenLDAP libraries ii libpopt0 1.14-4 lib for parsing cmdline parameters ii libtalloc1 1.2.0~git20080616-1 hierarchical pool based memory all ii libwbclient0 2:3.2.5-4lenny7 client library for interfacing wit ii netbase 4.34 Basic TCP/IP networking system ii samba-common 2:3.2.5-4lenny7 Samba common files used by both th smbfs recommends no packages. Versions of packages smbfs suggests: ii smbclient 2:3.2.5-4lenny7 a LanManager-like simple client fo -- no debconf information -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
