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 3.0.7.
Hello, 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!
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.
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. Jeremy.
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 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. Cheers, Jeremy.
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. Jeremy.