Bug 2008 - mount cifs doesn't follow symlinks like windows
mount cifs doesn't follow symlinks like windows
Product: CifsVFS
Classification: Unclassified
Component: user space tools
All Linux
: P3 normal
: ---
Assigned To: Steve French
Depends on:
  Show dependency treegraph
Reported: 2004-11-09 18:45 UTC by Clemens Schwaighofer
Modified: 2005-04-20 22:13 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Clemens Schwaighofer 2004-11-09 18:45:16 UTC
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.
Comment 1 Steve French 2004-11-09 19:18:42 UTC
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 
Comment 2 Steve French 2004-11-09 19:22:54 UTC
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)
Comment 3 Clemens Schwaighofer 2004-11-10 05:15:47 UTC
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.
Comment 4 Jens Benecke 2004-12-02 01:52:32 UTC
(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 
(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! 
Comment 5 ted_mcmanus 2005-01-06 14:07:48 UTC
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.
Comment 6 Clemens Schwaighofer 2005-01-19 23:58:01 UTC
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.
Comment 7 Simon Blackham 2005-02-22 10:18:50 UTC
(In reply to comment #4)

I think we have a similar - but different problem here...
We have amonget other machines.
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

Comment 8 Simon Blackham 2005-02-22 11:50:28 UTC
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
Comment 9 Anton Titov 2005-03-10 13:33:13 UTC
just wanted to tell you that

echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled

works fine but you should to this before mounting the share
Comment 10 Steve French 2005-03-18 23:19:56 UTC
workaround of disabling cifs unix extensions - reverts to windows like client
behavior as requested.
Comment 11 Clemens Schwaighofer 2005-04-20 22:13:45 UTC
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.