[Samba] Bug in kernel-space samba client (3.0.23a) on FC5 (2.6.17-1.2157_FC5)

[samba newbie]

On a client running FC5 with all packages updated from
yum (running samba 3.0.23a-1.fc5.1 and 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.

This is clearly a bug in the samba 3.0.23a
kernel-space client.

Can someone let me know if this has already been
identified and even fixed in 3.0.23b?

In case you're interested, here's some more info...

Here's a log of my console:

[EMAIL PROTECTED] madwifi]# mount -t cifs -o ro //[MY
SERVER]/Pictures /media/Pictures/
Password:
[EMAIL PROTECTED] madwifi]# mount -t cifs -o ro //[MY
SERVER]/Music /media/Music/
Password:
mount error 1 = Operation not permitted
Refer to the mount.cifs(8) manual page (e.g.man
mount.cifs)

Note, in this example, the first mount (for the
'Pictures' share) worked, but the second one failed.

If I restart my client machine, and access the 'Music'
share first, then that one will successfully mount,
but the 'Pictures' share won't.

The only information in /var/log/messages is:
Jul 31 15:48:33 talisker kernel:  CIFS VFS: cifs_mount
failed w/return code = -1

Echoing 1 into /proc/fs/cifs/cifsFYI produces no more
output in the log (this used to work in FC3 - how does
one produce more debugging data now?).  Disabling
linux extensions doesn't change the behaviour.

I will add that this is an improvement over the result
on my FC3 machine, where even one share cannot be
mounted using cifs.  In a previous e-mail to the samba
list where I was primarily dealing with another issue,
I said that running ethereal showed in that FC3 case
that the share password wasn't being correctly sent at
the same time as the TreeConnect AndX Request for the
share (the client in that case only sent '00' as the
password).  The server thus responded with
STATUS_WRONG_PASSWORD.

In the FC5 case, ethereal shows what appears to be the
encrypted form of a password (albeit the incorrect
one) being sent when the TreeConnect AndX Request
packet gets sent.  So, at first glance, it appears
that at least the password sending bug got fixed in
the newer version of the samba client (unfortunately,
it only got partially fixed).  The server
unfortunately responds with STATUS_WRONG_PASSWORD for
the reason mentioned above.  

Accessing both shares through the user-space smbclient
program works just fine.  



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Re: [Samba] Cannot access WD's NetCenter drive from linux

[samba newbie]

> 
> What version of Samba are you running on the client?
> 

3.0.10, as opposed to what I believe is 3.0.2 on the
server.

> If you suspect it's a problem with the client, try
> using the userspace
> program "smbclient" to reproduce the problem.

I tried to reproduce with smbclient, but failed.  I
opened two separate smbclient sessions.  In one, I ran
mget on a directory; in the other, while the mget was
running, I did individual gets on files in that
directory.  No problems occurred.  

So I don't think the server is the problem.

I need a non-interactive solution on the client side
(for scripting, etc.), so I'll try seeing whether the
samba client in FC5 works better.  If so, I'll just
upgrade my client machine.  

Maybe the mount.cifs problem will go away in the FC5
version as well.  If not, I'll need to post again to
this list. 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Re: [Samba] Cannot access WD's NetCenter drive from linux

[samba newbie]

Thanks once again, Adam.  Some more comments below...


--- Adam Nielsen <[EMAIL PROTECTED]> wrote:

> > * the client sends a Tree Connect AndX Request
> > specifying the correct share path but only '00' as
> the
> > password
> > * the server responds with STATUS_WRONG_PASSWORD.
> > 
> 
> This indeed does appear to be the problem.  Is
> 'mount' prompting you
> for the password, or are you specifying it as a
> mount option?  Does it
> make a difference doing it the other way?  (-o
> password=blah)
>

Makes no difference either way.

 
> If you disable CIFS UNIX extensions, does that make
> a difference?
> (echo 0 > /proc/fs/cifs/LinuxExtensionsEnabled) 
> Possibly the
> negotiation there is confusing the server.
> 

Makes no difference either.


> Does "mount \\whatever --verbose -o blah" give you
> any new information?
> 

Sure, but nothing useful.

> That's pretty much everything I can think of, so
> sorry I couldn't be
> more helpful!
> 
> Cheers,
> Adam.
> 

Hey, no worries.  I appreciate your efforts,
nonetheless.  I can only assume this is a bug in
mount.cifs (which may have been fixed in later
versions).  

But that's not the main problem anyway; the hang is. 
I've narrowed the problem behaviour down a bit.  It
happens when one process is already reading all the
files in a directory under a samba share, and another
process tries to do a read on one of the files in that
directory.  That's when the timeouts start to occur,
and things freeze up.  

In terms of user actions, this happens when I use an
image management program (picasa or gthumb, for
example) to show thumbnails of all the JPEG files in a
subdirectory of a samba share, and while the
thumbnails are still loading for that directory, I
double-click one of the thumbnails to try to view the
image.  

>From watching traffic in ethereal, the thumbnail loads
are generating a steady flow of Read AndX Request
packets from the client and Read AndX Response packets
from the server (the image program is requesting the
contents of each file).  When I double-click the file,
a new negotiate protocol request/response sequence
occurs.  The next Read AndX Request packet from the
client (from the process loading the thumbnails) runs
into problems: the server thinks the FID is invalid
(the FID is definitely valid, since the server had
returned it to the client and had transferred multiple
MB's worth of data for it already at this point). 
Pure speculation here, but maybe the kernel-space
samba client process gets confused and sends the read
request on the newly negotiated connection, which
causes confusion to ensue. 

A workaround is to let all the thumbnails load, and
then to access one file at a time.  No problems occur
if I do this.  This kinda sucks, but hey - it works at
least.





__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

Re: [Samba] Cannot access WD's NetCenter drive from linux

[samba newbie]

Adam,

THank you for responding.  Further questions below...


--- Adam Nielsen <[EMAIL PROTECTED]> wrote:

> User-level and share-level authentication are only
> terms for
> configuring the server, they both appear the same
> way on the client.

OK, then I need to rephrase my point here: any ideas
why mounting when specifying smbfs works, but
specifying cifs fails with STATUS_WRONG_PASSWORD (the
same password is given in both situations)?  I'm only
changing the fs option to mount; all other input is
the same.

When mounting with smbfs, ethereal shows that the
order of traffic is:
* the client sends an smb packet with a negotiate
protocol request
* the server replies with a negotiate protocol
response
* the client sends a Session Setup AndX Request
specifying the incorrect user and incorrect domain but
only '00' as the ANSI password
* the server responds with success and reports the
correct domain
* the client sends a Tree Connect AndX Request
specifying the correct share path and what I presume
is the encrypted version of the actual password
* the server responds with success.

With cifs specified as the filesystem, something
slightly different occurs:
* the client sends an smb packet with a negotiate
protocol request
* the server replies with a negotiate protocol
response
* the client sends a Session Setup AndX Request
specifying the incorrect user and domain and what I
imagine is the actual password in ANSI (I presume this
is encrypted) and in unicode 
* the server responds with success and reports the
correct domain
* the client sends a Tree Connect AndX Request
specifying the correct share path but only '00' as the
password
* the server responds with STATUS_WRONG_PASSWORD.

The fact that, with cifs, the password is not being
sent at the same time as the share specification would
seem to suggest that something incorrect is taking
place in the client software when sending the request.
 This is why I was asking whether I needed to specify
some different options to mount when dealing with
cifs.


> 
> > At this stage, I'm stumped.  I have no access to
> the
> > server logs (since the NetCenter is a black-box
> > appliance). 
> 
> But you said you could download the source?  You
> could recompile that
> and enable SSH or something, presumably?  They may
> even have some sort
> of SSH or telnet access already built in.

There are no instructions provided.  I have no idea
what the toolchain requirements are, so I don't even
know if I can compile it.  I'll certainly try,
however, if I have the time (not looking forward to
this).

> 
> > Any ideas?  Is there anything else I can do to
> gather
> > more debugging data?  Any mount options I should
> try?
> 
> You could try using Ethereal and see what's actually
> going over the
> network when the share locks up, but beyond that it
> could be tricky
> without access to the server.

I'll try this as well.


> 
> Cheers,
> Adam.
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba

[Samba] Cannot access WD's NetCenter drive from linux

[samba newbie]

Hello folks.

I bought a Western Digital NetCenter drive since it
seemed a low-cost way of having a NAS in my home.  The
NetCenter drives run GPL'ed software (I downloaded the
source from Western Digital's Web site, and it refers
to Broadcom's "BCM478x Linux NASoC Software."  The src
directory also contains samba 3.0.2.)

The device offers two ways of accessing your data:
through CIFS, or through NFS.  There is no security on
NFS shares.  You can specify share-level passwords for
CIFS, which is better than nothing, so that seemed to
be the way to go.  Also, my data lives on a Windows
box, so CIFS made sense.

Now, I want to access that data using Samba from 
Fedora Core 3 (2.6.12-1.1378_FC3).  On my Linux box, I
mount one of the shares using:

mount -t smbfs -o ro //192.168.0.251/Pictures
/media/Pictures

This prompts me for a password, and upon correct
entry, it goes ahead and mounts the share.  So far, so
good.

I can also go ahead and read the directory structure
without any problems.  Running the following for 20
minutes:

while [ 1 ]; do find /media/Pictures -print -exec stat
{} \; >/dev/null; sleep 1; done

caused no problems.

However, as soon as I actually tried reading a file,
access to that directory hung.  I could no longer 'ls'
anything in that directory.  The stat command reported
input/output errors.

/var/log/messages is full of errors along the lines
of:
Jul 24 16:57:51 mj-desktop kernel: smb_add_request:
request [f5d3b980, mid=10175] timed out!
Jul 24 16:57:51 mj-desktop kernel: smb_lookup: find
//sub_folder failed, error=-5

I can also no longer umount that directory; Linux
thinks the device is busy.  I can't rmmod the smbfs
kernel module.  The only way to recover is to reboot
the machine.

If, on my Linux machine, after rebooting, I mount the
share and quickly try to cp a file over from the
remote share to my linux machine, it occasionally
works.  So, for a very short bit of time (on the order
of a minute), the access works correctly. 

I found through google that mounting using cifs should
allow me to gather more debugging info on the client
side (since I can do 'echo 1 >
/proc/fs/cifs/cifsFYI').  So I tried to mount my share
using 'mount -t cifs'.  Unfortunately, this fails with
return code -1.  I think this is because the mount is
trying to do user-level authentication (since it
correctly sends my share-level password, but also
reports to the server that the user is 'root').  I get
back:

Status code returned 0xc06a
NT_STATUS_WRONG_PASSWORD

There is no documentation on the mount.cifs man page
to force share-level authentication.

At this stage, I'm stumped.  I have no access to the
server logs (since the NetCenter is a black-box
appliance). 

I should note that access from my Windows box worked
fine, at least for writing.  I spent the last few days
backing up over 100GB of music and pictures to shares
on the NetCenter from my Windows machine.  It's a
shame I can only access it from that machine.  It
makes the idea of buying the device pointless: if the
only machine that can access it is my Windows box,
it's cheaper (and much faster) to simply hook up an
external USB drive to it.  But I digress...

Any ideas?  Is there anything else I can do to gather
more debugging data?  Any mount options I should try?

I should mention that similar access from Mac OS X
(10.4.7) doesn't appear to hang.  I can mount using
the same command-line options, and access the data
without difficulty.  So maybe this is an issue with
the kernel on my linux box?  Is this a known issue
that is solved in later kernels?

Thanks!

P.S.  I had submitted a support request to Western
Digital asking for help with this problem (I had also
asked whether they could let me know how to access the
logs or how to roll my own firmware from the source). 
They just wrote back saying that Broadcom downsized
the department that wrote the software, and thus they
have no answers for me.  Lovely.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around 
http://mail.yahoo.com 

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/listinfo/samba