On a client running FC5 with all packages updated from yum (running the 2.6.17-1.2157_FC5 linux kernel), I cannot access multiple samba shares that have share-level security using cifs. 0. To reproduce, use a server that serves two shares with share-level security. Make sure the shares have different passwords. 1. Using the standard mount command and specifying cifs as the fs, mount the first share (it doesn't matter which one you pick). If you watch the ethereal traffic, pay attention to (what I presume is the encrypted form of) the password that gets sent as part of the TreeConnect AndX Request packet. Let's call this hexadecimal password string "A". 2. Now attempt to mount the second share using the mount command as well. This will fail with an "Operation not permitted" error, and ethereal traffic will show the server responded with STATUS_WRONG_PASSWORD. If you watch the ethereal traffic closely, you'll notice that no matter what password you try to send for this second share, the client software sends string "A" (which - as previously mentioned - is the password for the first share) to the server in the TreeConnect AndX Request packet, and thus the server correctly rejects the password.
Steve, please be aware that I filed this bug in the RedHat bugzilla as well: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201081 The samba guys there made me run straces to confirm that this is not a user-space mount.cifs issue, and is indeed a kernel-level issue (the straces confirmed that mount.cifs is doing the right thing). I wanted them to be aware of the bug so that as soon as it gets fixed, they know about it, and include the fix in the next kernel rpm they release.
To avoid having to boot an older Windows9x machine, do you remember an easy way to configure Samba for your example?
I'm sorry, Steve, but I don't. I'm using a Western Digital NetCenter external hard drive (with only consumer-grade NAS features, including no user-level security for samba shares) as the server. That drive runs 2.4.x linux and 3.0.2 samba. I have no access to its internals, including its logs or its samba configuration. If you want, e-mail me directly at samba_help_needed@yahoo.com, and I'll expose the two samba shares I was using to the internet for the course of your testing. I'd prefer not to because of the obvious security considerations, but if that's the only way you'll fix this bug, I'll take that chance. :)
Steve, do you still need help setting up an environment for this? My offer is still open...
I have reproduced this bug. I don't know the right way to approach this yet - there are two obvious alternatives 1) create another smb session structure on this tcp socket for this mount (tconinfo struct) 2) try to add a password field to the tconinfo struct I am leaning toward the former but it is not a small, trivial change and will require more thought to do right.
Steve, it's been a few weeks; any update on this?
Hi again Steve. Here's another reminder to do something about this bug. It's been sitting without activity for nearly three months now. I tested this with the latest kernel that FC5 released (2.6.18-1.2200.fc5), and the bug is alive and well.
Created attachment 2504
Hi Steve. The last update to this bug from a Samba developer (you) occurred almost 9 months ago (when you confirmed the existence/reproducibility of the bug). Can you please tell me why this bug is stuck in limbo? If you don't have the time to work on it, can you please re-assign it to someone who can fix it? Note that you're cc'ed on this bug through the redhat bugzilla as well (see comment 1 for a link to it).
Is now fixed in cifs-2.6.git and will be in 2.6.29 kernel but the patch is in multiple parts. Three pieces: 1) http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=ee3473add0da7ce5a4258225b708e035fff023cc 2) http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=e47b85ff7e545719cb17b0344b4f598ed09eb77d 3) http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=bf9c54cda7b4581cf00cd64591b4af1f92f646f2
Has been fixed for quite a while now (although it took a big change to allow it). Please reopen if you find problems.