The Samba-Bugzilla – Bug 1515
Symlink give a wrong path when "unix extensions = yes".
Last modified: 2004-10-20 11:21:10 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.
This is fixed in the current 3.0 svn tree.
In what version of samba can we expect this fix? I still have this problem with
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.
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.
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.
You didn't listen. You obviously don't know how to submit a proper bug report.
Please learn and resubmit.
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.
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?
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
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.
Jeremy: All right, thank you. What is it then that Gerald claims was fixed in
the current 3.0 svn tree?
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.