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
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
okay, I will try that out with either the patch or wait until it is included in
furthermore, out of interest, I will try to play around with the proc settings.
(In reply to comment #2)
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
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
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)
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.