This worked before I upgraded from RHEL 5.1 Beta to GA. After mounting a cifs share, something goes wrong with the mountpoint: [root@host ~]# ll /mnt total 24 drwxr-xr-x 2 root root 4096 Nov 5 08:50 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/RHN-Content-ISO/RHEL4/Base/tree /mnt/Sat-tree Password: [root@host ~]# ll /mnt/Sat-tree ls: /mnt/Sat-tree: No such file or directory [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 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.1 (Tikanga)
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