Bug 1515 - Symlink give a wrong path when "unix extensions = yes".
Summary: Symlink give a wrong path when "unix extensions = yes".
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: File Services (show other bugs)
Version: 3.0.0
Hardware: x86 Linux
: P3 normal
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
Depends on:
Reported: 2004-07-11 08:39 UTC by Andrey A. Belikov
Modified: 2004-10-20 11:21 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Andrey A. Belikov 2004-07-11 08:39:57 UTC
I have kernel 2.6.7 and samba 3.0.0
When i type "unix extensions = yes" in my smb.conf, and users with kernel 2.4.26
(with smbfs and Enable Unix Extensions) mount to my share they see link's path
as "../../someting" and the linux think that dir "something" is in the client's
partition, no on server. The same with kernel 2.6.2 and 2.6.7 (with smbfs and
with or without CIFS support). In Windows XP, kernel 2.4.22, kernel 2.4.26
(without Enable Unix Extensions) this link shows as dirictory and normaly opens.

If in my smb.conf i type "unix extensions = no" all kernels work ok.
Comment 1 Gerald (Jerry) Carter (dead mail address) 2004-07-21 12:42:20 UTC
This is fixed in the current 3.0 svn tree.
Comment 2 Christoffer Hammarström 2004-09-22 07:44:10 UTC
In what version of samba can we expect this fix? I still have this problem with
Comment 3 Jens Benecke 2004-10-19 07:28:45 UTC
I still have this problem in 3.0.7 (SuSE 9.1, Kernel 2.6.5). This is serious 
because it affects a couple dozen Linux workstations that cannot access a 
central fileserver for cricital data, and it is a bit embarassing in front of 
the Windows admins that snicker at you because "so... Linux is incompatible 
with itself, eh?". 
I would really like to see a patch for 3.0.7 for this. 
Or a 3.0.8 that includes the patch RSN. 
Thank you! 
Comment 4 Jeremy Allison 2004-10-19 10:41:44 UTC
Please give *exact* (and I really mean exact) instructions on how to reproduce
this. This currently doesn't contain enough information on how to reproduce and
fix this if it is a problem.

Comment 5 Christoffer Hammarström 2004-10-19 11:12:27 UTC
Jeremy: The problem exactly matches the description in this bug. A symlink is
interpreted by the client instead of the server under "unix extensions = yes".
I still see this with 3.0.7 when i'd have expected this fix to be in 3.0.7.
Comment 6 Jeremy Allison 2004-10-19 11:24:55 UTC
You didn't listen. You obviously don't know how to submit a proper bug report.
Please learn and resubmit.

Comment 7 Christoffer Hammarström 2004-10-19 11:29:52 UTC
I have a machine called "ran" running smbfs under linux 2.4.27.
ran connects to share "backup" on machine "kvaser", running smbd 3.0.7 with
"unix extensions = yes". Share "backup" corresponds to kvaser local directory
"/srv/backup". "/srv/backup/www" is a symlink which contains "../../home/www"
and therefore points to "/home/www". ran has mounted this share on kvaser local
directory "/mnt/smb/kvaser/backup", and sees and interprets the symlink as
pointing to ran local directory "/mnt/smb/home/www" which doesn't exist. I
expected kvaser to display the symlink to ran as a directory, "/home/www" on kvaser.
Comment 8 Christoffer Hammarström 2004-10-19 11:32:15 UTC
Jeremy: First, i read your first comment as directed to Jens. It's not really
fair to say "You didn't listen." when possibly Jens hasn't even seen your
comment yet, just because i chimed in.
Second, the bug was already marked FIXED. I just want to know if the fix was
supposed to be in 3.0.7, or in 3.0.8. If it went into 3.0.7, we're probably
seeing another problem. Would be nice to know, right?
Comment 9 Jeremy Allison 2004-10-19 11:47:02 UTC
Christoffer Hammarström   wrote :

>First, i read your first comment as directed to Jens.

Actually no, it was directed at you :-). Thanks for following up with a proper
bug report.

smbfs doesn't correctly support the unix extensions as far as I know, and is not
supported by the Samba Team. cifsvfs is the supported version of the client
code, and symlinks definately work using this client filesystem. Please use the
version of cifsvfs for your kernel.


Comment 10 Christoffer Hammarström 2004-10-20 01:40:07 UTC
Jeremy: All right, thank you. What is it then that Gerald claims was fixed in
the current 3.0 svn tree?
Comment 11 Jeremy Allison 2004-10-20 11:21:10 UTC
What Jerry is talking about is the fixes I added to 3.0.x SVN to make this work
correctly with CIFSFS in the 2.6 (and backported 2.4) Linux kernels.
I'm going to start working with the Linux kernel people to see if we can get
some support from them for smbfs bugs but at the moment we're only supporting
one Linux kernel CIFS client filesystem and it's cifsfs (as Steve French, the
author) is also a Samba Team member with commit access to the server code too.