Bug 3992 - Cannot mount >1 share if shares have share-level security
Summary: Cannot mount >1 share if shares have share-level security
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: kernel fs (show other bugs)
Version: 2.6
Hardware: x86 Linux
: P3 major
Target Milestone: ---
Assignee: Steve French
QA Contact:
Depends on:
Reported: 2006-08-02 12:38 UTC by samba_help_needed
Modified: 2009-05-14 17:33 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description samba_help_needed 2006-08-02 12:38:50 UTC
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

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

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.
Comment 1 samba_help_needed 2006-08-02 14:33:27 UTC
Steve, please be aware that I filed this bug in the RedHat bugzilla as well:

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.
Comment 2 Steve French 2006-08-02 19:07:49 UTC
To avoid having to boot an older Windows9x machine, do you remember an easy way to configure Samba for your example?
Comment 3 samba_help_needed 2006-08-02 19:15:57 UTC
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. :)
Comment 4 samba_help_needed 2006-08-04 13:18:59 UTC
Steve, do you still need help setting up an environment for this?  My offer is still open...
Comment 5 Steve French 2006-08-04 21:10:12 UTC
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.
Comment 6 samba_help_needed 2006-09-15 13:23:59 UTC
Steve, it's been a few weeks; any update on this?
Comment 7 samba_help_needed 2006-10-26 18:36:18 UTC
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.
Comment 8 Spammer 2007-04-28 04:25:56 UTC
Created attachment 2504
Comment 9 samba_help_needed 2007-04-29 15:39:11 UTC
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).
Comment 11 Steve French 2009-05-14 17:33:12 UTC
Has been fixed for quite a while now (although it took a big change to allow it).  Please reopen if you find problems.