I have a sambashare that has a symlinked directory inside. This symlink goes to a different directory on a different mount point on the server. In Windows I can browse that directory and see the content, but on a mount.cifs mounted share I see just a "dead symlink" and I can't enter it.
This should be fixed in the current development tree (http://cifs.bkbits.net/linux-2.5cifs) and I will ask to have this included in 2.6.10
Sorry misread the comment. I take that back about it being fixed. On Windows symlinks (reparse points, I have changed it so I do not follow them on the client) so they can now be traversed. This issue is harder - the server knowns that this is from a client which supports the CIFS Unix extensions - thus the server is not following the symlink automatically for the client (probably safer that way). I assume that opening the file from the client would not help. I can do some experiments to make sure. Disabling the Unix Extensions probably would not help (echo 0 > /proc/fs/cifs/LinuxExtensionsEnable)
okay, I will try that out with either the patch or wait until it is included in 2.6.10 tree. furthermore, out of interest, I will try to play around with the proc settings.
(In reply to comment #2) Hello, we have the same problems here. We have a central company wide file server using Samba 3.0.7, and clients using Samba 3.0.4 through 3.0.9 (different SuSE versions) and Linux kernels 2.6.5 and 2.6.8. The file server exports ONLY one share which has a lot of symlinks to its internal mount points, which are outside this share's scope. KDE's Konqueror 3.2.1 (using smb://server/share), Windows (NT, 2000, XP), and "smbclient //server/share" all work fine (i.e. resolve or ignore the symlinks). But mounting this share via smbmount, gives you only broken symlinks. "echo 0 > /proc/fs/cifs/LinuxExtensionsEnable" doesn't change this. Please have a closer look at this, I think one would need to be able to specify on the _server_ that symlinks pointing _outside_ the share's scope should be followed, even if the client supports UNIX extensions - while still supporting normal symlinks for use within the share (but not allowing them to point outside the share's scope). This perhaps needs some more thought, because it can open security holes. If the server resolves symlinks that point "outside" the share, then an evil client must not be able to create such symlinks. Perhaps it is feasible to resolve such symlinks only if they are created by a certain user (which cannot log in via Samba, e.g. root). Maybe it is better done on the client side entirely. If the client detects a "broken" symlink, it switches to the way Windows would "see" this link and lets the server resolve it just as it does now. If that target doesn't exist either (because the symlink is *really* broken) or is inaccessible (permissions etc). This would also solve security problems because the server admin could disable "wide links" and then "outside" symlinks would never be resolved on the server side (but could be used normally for clients that want to create a link on a Samba share that points somewhere to their local file system, or a different Samba share). Thank you! Jens
The "broken" symlinks in the server share are not actually dead. Rather, the client is trying to follow them on the client machine's own filesystem. At least this appears to be the case with my 3.0.7 smbclient running against 3.0.4 samba server. 2.2.7a smbclient reads the symlinked files on the server just fine with the same 3.0.4 server.
Symlinks still not followed on CIFS mounted samba shares. I have now 2.6.10-gentoo-r6 on the client side and on the server side 3.0.10-debian. Still the symlink in the share is a broken link on the client. I have all CIFS attributes (extended, etc) compiled into the cifs module.
(In reply to comment #4) SDB@rfa-ltd.co.uk I think we have a similar - but different problem here... We have amonget other machines. SERVER - An old SCO OS5 SUSE - a suse linux 8.2 m/c running SAMBA 2.27 it access server directories as /Net/SERVER/pinacle/... [b]via NFS[/b] WIDGET - an XP PRO Laptop which accesses \\SERVER\PINACLE\... where ... are ALL symlinks - eg rfa -> /Net/SERVER/pinacle/rfa all symlinks are resolved under XP. I run programs on widget on data and using runtimes (RM/cobol) that come from the resolved symlinks. CAIRN - a suse linux 9.2 m/c running SAMBA 3.075 if I mount //sumit/pinacle on /Net/SUMIT/pinacle the symlinks are not resolved The CAIRN mount line in /etc/fstab... //sumit/pinacle /Net/SUMIT/pinacle defaults,username=...,password=... 0 0 The SUMIT mounts are of the form... pinacle:/u /Net/pinacle/u defaults,user 0 0 SAMBA was set up using WEBMIN on SUMIT I will try the orthogonal connection to see if SAMBA 3.075 is the same
The orthogonal connection works perfectly - first time - then ground to a halt when I tried to access via konqueror. Started to look at /Net/CAIRN/pinacle/rfa (Konqueror on SUSE) - hung Tried ls -l on /Net/SERVER/src (on CAIRN) and it hung/stalled CTRL-ALT-BS on SuSE and immediately the ls -l completed on CAIRN Tried again - worked - but VERY slow SERVER mounted on CAIRN via NFS CAIRN (via SAMBA 3.0.7-5) mounted on SuSE and symlinks to SERVER (via NFS) Example symlink (/Net/CAIRN/pinacle/)rfa -> /Net/SERVER/src/rfa Meanwhile WIDGET (XP PC) connected through to \\CAIRN\pinacle\rfa in no time
just wanted to tell you that echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled works fine but you should to this before mounting the share
workaround of disabling cifs unix extensions - reverts to windows like client behavior as requested.
Okay, this works. One thing, if you have already some shares mounted from that server, you need to unmount _ALL_ of them, only then the proc setting gets in affect.