Bug 370501

Looks like you may be connecting to the share as "root" but that user doesn't
actually have proper credentials to access the "tree" directory. A reproducer
would be the most helpful thing. What kind of server is this?

Another thing you can do would be to unmount the share, turn up cifsFYI:

    # echo 7 > /proc/fs/cifs/cifsFYI

...and then mount the share and try to access the directory. After that, collect
dmesg output and post that here:

    # dmesg > /tmp/dmesg.out

...also please get this entry from /proc/mounts so I can see what options it
ended up with:

    # grep /mnt/Sat-tree /proc/mounts

Also, can you tell me what kernel rev you're using, and what version of the
samba-client package you have installed?

Created attachment 251461 [details]
dmesg > /tmp/dmesg.out

Provided per request from jlayton.

Looks like the first command did the trick:

[root@host ~]# echo 7 > /proc/fs/cifs/cifsFYI
[root@host ~]# ll /mnt
total 20
?--------- ? ?    ?       ?            ? /mnt/Sat-tree
drwxr-xr-x 2 root root 4096 Oct 21 19:54 test
drwxr-xr-x 2 root root 4096 Oct 21 21:56 test2
drwxr-xr-x 2 root root 4096 Nov  4 16:28 test3
drwxr-xr-x 2 root root 4096 Nov  4 18:55 test4
drwxr-xr-x 2 root root 4096 Nov  4 18:57 test5
[root@host ~]# mount -t cifs //VAIO/Office /mnt/test
Password: 
[root@host ~]# ll /mnt/test
total 1
-rwxrwSrwt 1 root root 62 Nov 15  2004 desktop.ini
drwxrwxrwx 1 root root  0 Nov 15  2004 My Music
drwxrwxrwx 1 root root  0 Nov 15  2004 My Pictures
drwxrwxrwx 1 root root  0 Nov 15  2004 My Videos
drwxrwxrwx 1 root root  0 Oct  5  2006 Picture Package
drwxrwxrwx 1 root root  0 Nov  7 23:07 RHN-Content-ISO
drwxrwxrwx 1 root root  0 Apr 15  2007 Symantec
[root@host ~]# dmesg > /tmp/dmesg.out
[root@host ~]# grep /mnt/Sat-tree /proc/mounts
//VAIO/Office /mnt/Sat-tree cifs
rw,mand,unc=\\VAIO\Office,username=root,rsize=16384,wsize=57344 0 0
[root@host ~]# grep /mnt/test /proc/mounts
//VAIO/Office /mnt/test cifs
rw,mand,unc=\\VAIO\Office,username=root,rsize=16384,wsize=57344 0 0

Server is XP Home Edition, Version 2002, SP2, running on an Intel Core Duo that
is on a local network with the RHEL 5.1 laptop.

Additional info:

[root@host ~]# uname -a
Linux host.spurgeon.net 2.6.18-53.el5xen #1 SMP Wed Oct 10 17:06:12 EDT 2007
i686 i686 i386 GNU/Linux
[root@host ~]# rpm -qi samba-client
Name        : samba-client                 Relocations: (not relocatable)
Version     : 3.0.25b                           Vendor: Red Hat, Inc.
Release     : 0.el5.4                       Build Date: Mon 09 Jul 2007 06:24:28
PM EDT
Install Date: Sun 21 Oct 2007 07:39:10 PM EDT      Build Host:
hs20-bc1-5.build.redhat.com
Group       : Applications/System           Source RPM:
samba-3.0.25b-0.el5.4.src.rpm
Size        : 12755316                         License: GNU GPL Version 2
Signature   : DSA/SHA1, Fri 13 Jul 2007 12:33:23 PM EDT, Key ID fd372689897da07a
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://www.samba.org/
Summary     : Samba (SMB) client programs.
Description :
The samba-client package provides some SMB clients to compliment the
built-in SMB filesystem in Linux. These clients allow access of SMB
shares and printing to SMB printers.

Ok, so the upper directories in this tree seem to not have as restrictive an ACL
as the lower one. What happens if you do this?

# stat /mnt/test/RHN-Content-ISO/RHEL4/Base/tree

I'll look over the dmesg output in a bit...

It would have been best to unmount all of the CIFS shares so we could see the
session setup and know that it wasn't reusing old sessions and connections.
Still I think we can tell something here:

So for the first bit, it attempts to revalidate this path:

 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 17 with uid: 0
 fs/cifs/inode.c: Revalidate: \RHN-Content-ISO/RHEL4/Base/tree inode 0xe5c76da0
count 1 dentry: 0xec764338 d_time 0 jiffies 17833323
 fs/cifs/inode.c: Getting info on \RHN-Content-ISO/RHEL4/Base/tree

...it does a session setup and appears to have fallen back on a guest login. I'm
guessing the authentication as root failed. Do you have an actual windows user
named "root" on this machine?

 fs/cifs/sess.c: sess setup type 1
 fs/cifs/transport.c: For smb_command 115
 fs/cifs/transport.c: Sending smb:  total_len 240
 fs/cifs/connect.c: rfc1002 length 0x85)
 fs/cifs/misc.c: Null buffer passed to cifs_small_buf_release
 fs/cifs/sess.c: ssetup rc from sendrecv2 is 0
 fs/cifs/sess.c: Guest login
 fs/cifs/sess.c: UID = 2048 
 fs/cifs/sess.c: bleft 88
 fs/cifs/sess.c: words left: -1
 fs/cifs/sess.c: ssetup freeing small buf e605f3c0
 fs/cifs/connect.c: CIFS Session Established successfully

Tree connect works:

 fs/cifs/transport.c: For smb_command 117
 fs/cifs/transport.c: Sending smb of length 78
 fs/cifs/connect.c: rfc1002 length 0x42)
 fs/cifs/connect.c: Tcon flags: 0x1 
 fs/cifs/cifssmb.c: reconnect tcon rc = 0

...I think this is the actual QueryPathInfo (sort of equivalent to a GETATTR):

 fs/cifs/transport.c: For smb_command 50
 fs/cifs/transport.c: Sending smb of length 138
 fs/cifs/connect.c: rfc1002 length 0x27)
 fs/cifs/connect.c: invalid transact2 word count
Status code returned 0xc0000033 NT_STATUS_OBJECT_NAME_INVALID

...server returns NT_STATUS_OBJECT_NAME_INVALID. Usually this error means that
you have an invalid pathname. i.e., it has embedded wildcards or other invalid
characters in it. It might be interesting to see a network capture while doing
"ll /mnt".

Perhaps the client is munging the pathname that it's sending to the server?

Actually, please do that. On the client:

# tcpdump -i <interface> -s 0 -w /tmp/cifs.pcap host 192.168.1.100

...then do:

# ll /mnt
# stat /mnt/Sat-tree

...then kill the capture and attach /tmp/cifs.pcap to this BZ.

# stat /mnt/test/RHN-Content-ISO/RHEL4/Base/tree
  File: `/mnt/test/RHN-Content-ISO/RHEL4/Base/tree'
  Size: 0               Blocks: 0          IO Block: 16384  directory
Device: 17h/23d Inode: 205294      Links: 1
Access: (0777/drwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2007-11-08 08:13:49.015625000 -0500
Modify: 2007-11-05 07:46:49.031250000 -0500
Change: 2007-11-05 07:46:49.031250000 -0500

No user named root exists on the XP box.

Created attachment 251491 [details]
tcpdump -i eth1 -s 0 -w /tmp/cifs.pcap host 192.168.1.100

Capture shows this:

804	18.265805	192.168.1.64	192.168.1.100	SMB	Trans2 Request, QUERY_PATH_INFO,
Query File All Info, Path: \RHN-Content-ISO/RHEL4/Base/tree

...so it looks like the client is indeed messing up the name. If I'm not
mistaken, the forward slashes in that name should be changed to backslashes.
I'll see if I can come up with a way to reproduce this.

Testing the 8.1.15 kernel...

When mounting the subdirectory of a share, it looks like the 8.1.15 kernel just
ignored any path components after the share. So on a 8.1.15 kernel, mounting:

//VAIO/Office/RHN-Content-ISO/RHEL4/Base/tree

...or...

//VAIO/Office

gives you the same result. This seems broken to me, since you're not getting
what you ask for. So I don't consider this a regression, though it's not working
correctly.

Upstream seems to do the same thing here, so we'll probably need to push a patch
there first...

The problem seems to be that build_path_from_dentry() doesn't convert the
slashes in the prepath to backslashes. This seems to be a known issue, but
there's no good way to fix it:

        /* DIR_SEP already set for byte  0 / vs \ but not for
           subsequent slashes in prepath which currently must
           be entered the right way - not sure if there is an alternative
           since the '\' is a valid posix character so we can not switch
           those safely to '/' if any are found in the middle of the prepath */
        /* BB test paths to Windows with '/' in the midst of prepath */
        strncpy(full_path, CIFS_SB(direntry->d_sb)->prepath, pplen);
        return full_path;

...so we have a dilemma. After mounting, suppose we have a prepath on a share
like this:

\RHN-Content-ISO/RHEL4/Base/tree

...we could just try to switch all of the slashes here to backslashes, but what
do we do with a legit windows path like this:

\foo/bar\baz\biz

...i.e. if there's a path component with a legitimate embedded '/' in the name,
how do we deal with that?

This is just plain ugly...

The good news is that you can likely work around this problem by changing the
delimiters in the prepath component to backslashes. i.e.:

//VAIO/Office/RHN-Content-ISO\RHEL4\Base\tree

...I need to ponder this a bit and see if there's a way that we can reliably
convert the prepath string for all cases. This might actually be a job for
mount.cifs...

Changing tagline to something more descriptive.

Also, I'm going to reduce the sev/pri. Given that this didn't work correctly
before, and only occurs when mounting subshares then I don't think we can call
this an urgent problem.

Feel free to re-raise it if you disagree, but please provide some justification
if you do...

On a related note...

There seem to be problems with delimiter conversion in general with submounts. I
can mount this with no problem:

\\dantu.usersys.redhat.com\public

...but this fails:

\\dantu.usersys.redhat.com\public\p1

When you change all '\' to '/', they both work.

*** Bug 371701 has been marked as a duplicate of this bug. ***

I think both problems here are the fault of mount.cifs, so changing this to a
samba bug.

Created attachment 252171 [details]
patch -- allow prefixpath to start with '\\' and change '/' to '\\' in prefixpath

There are 2 problems with mount.cifs:

a) it expects that any prefixpath string will start with a '/'. If using
"native" style UNC strings, it fails to parse out the prefixpath and leaves it
appended to the sharename.

b) if the prefixpath uses '/' as a delimiter, it doesn't convert that to a
"native" prefixpath and neither does the kernel. So the kernel ends up stuffing
that string at the beginning of the path when it builds one from a dentry and
that confuses windows servers

This patch should fix both problems. It allows the prefixpath to start with
'\\', and adds a routine that converts delimiters in the prefixpath from '/' to
'\\'. If a '/' is escaped with a '\\' before it, it passes the '/' as is.

That should allow us to deal with an embedded '/' in a path component, but
we'll probably need to document that in the manpage if this is acceptable.

Thoughts?

Created attachment 252681 [details]
patch -- add function to normalize UNC string

The last patch had a bug that would crop up if there were any escaped slashes.
This patch should do the right thing and I think it's a bit cleaner.

Incidentally, on my first pass with this, I tried to turn all of the delimiters
into '\\' (including the first 2 chars in the unc and the delimiter between the
host and sharename). That made /proc/mounts print the device string like this:

\134\134server.foo.redhat.com\134public

It would be nice if the kernel would print '\\' correctly here, but it
currently doesn't. Also, I'm not too thrilled with the way that the prefixpath
disappears from the device portion of the mount string.

It also doesn't appear in the options list in /proc/mounts. We may also need to
consider some kernel patches to fix that up.

Created attachment 253241 [details]
patch -- fix several problems with subshare mounts

Hopefully final patch :-)

This fixes several problems with subshare mounts. I'll plan to send this out to
the lists early next week.

Rick, if you're able to test this patch on your setup then that would be most
helpful.

Forgot to add the other issue to the description:

d) If the client has to retry the mount with an uppercase sharename, it
doesn't also uppercase the prefixpath (not sure if that's a real problem
but it seems inconsistent).

Patch sent to upstream linux-cifs-client and samba-technical mailing lists:

Subject: [PATCH] mount.cifs: fix handling of subdirectories of shares

Created attachment 256911 [details]
patch -- fix several problems with subshare mounts (try 2)

This patch is essentially the same as the one from yesterday. I added a small
replace_char helper function and have the code call that in a couple of places
rather than doing it inline.

Sent upstream to linux-cifs-client, samba-technical, and to Steve French
directly:

Subject: [PATCH] mount.cifs: fix several problems when mounting subdirectories
of shares

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0180.html