[Pkg-samba-maint] Bug#551203: /sbin/mount.cifs: option to force legacy behavior of symlinks, even if CIFS extensions are enabled

[Christian Pernegger]

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