Steven French | 5 Jan 2004 04:34
Picon
Favicon

Re: [Bug 899] New: mount.cifs does not allow a password with a comma in it

This is a valid bug but a little tricky to fix since the kernel mount options are comma delimited (not just what is passed to the mount.cifs utility). I have a rewrite of large sections of the mount.cifs.c mount helper source that needs to be checked in - and it will be a good thing to look at next.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
http://lists.samba.org/mailman/listinfo/linux-cifs-client
Michael Pflüger | 7 Jan 2004 14:35
Picon
Picon

du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

Well, the topic says it, it reports about 157MB for a directory that 
actually contains ~940 files with about 5GB. ls -l however shows all 
files with their correct sizes, and df shows the correct fre and used 
space on the share too.
Does 0.9.9a solve it, and how can i get it for kernel 2.6, afaik 
BitKeeper is commercial software, and i dont want to buy BK just to 
download a working cifs for my kernel :/

regards
Michael
Steven French | 7 Jan 2004 18:27
Picon
Favicon

Re: cfs client


Robert,
If you are not using the mount helper (mount.cifs), the mount syntax for 2.4 requires a parameter after the -o (unc=//ip_address/share) that is not required for 2.6.   That is an obvious possible reason for differences between 2.4 and 2.6 mount behavior.   Turning on informational logging ("echo 1 > /proc/fs/cifs/cifsFYI") will allow more detailed information to be returned about mount failures to the kernel message log (dmesg).  

No good solution for returning more granular mount errors on 2.4 has been proposed.  Since 2.4 kernel itself (unlike 2.6 which fixed this) does not allow return codes to be passed back from the key kernel vfs mount routine (get superblock), the sys_mount API uses a generic error when mount of network filesystems fail (unless the mount code is put in userspace, outside the kernel, as smbfs does, in which case this problem is avoided but it createst others).   The most recent mount helper source (mount.cifs.c) in Samba CVS is much improved but does not have a solution for this 2.4 kernel specific problem with better return codes on mount.

There are some not so elegant solutions for returning better errors on mount in 2.4 - e.g. stuffing the return code in /proc/fs/cifs/error.  The obvious solutions such as putting the errors in errno or environment variables or overwriting the mount parms with the error on return don't seem feasible.   Alternative solutions would be welcome since this is a usability problem with 2.4


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com


"Robert Rothberg" <rrothbe <at> emory.edu>

01/06/2004 04:39 PM

       
        To:        Steven French/Austin/IBM <at> IBMUS
        cc:        <client <at> lists.samba.org>
        Subject:        Re: cfs client



I built a Red Hat box with 2.6 SE Linux and 2.4.20 Linux. I implemented CIFS in the 2.6 version with few problems. I saved my mount command in a little script to save typing. After I patched and built my 2.4 kernel with the CIFS built-in, I boot up into this kernel version and try to run this same script and it always fails.
 
mount: wrong fs type, bad option, bad superblock on .....
 
I have tried rebuilding the kernel with exactly the same parameters as my working 2.6. I would like to be able to patch any production machine quickly and easily and mount a cifs share.
 
My second question is this. Can I mount the other way, I mean from a Windows box to the Unix machine with the CIFS running?
 
Thanks for your help.
 
----- Original Message -----
From: Steven French
To: Robert Rothberg
Sent: Monday, December 22, 2003 4:18 PM
Subject: Re: cfs client

Take a look at the file fs/cifs/README and the project page (http://us1.samba.org/samba/Linux_CIFS_client.html) and then send subsequent questions to linux-cifs-client <at> lists.samba.org


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
http://lists.samba.org/mailman/listinfo/linux-cifs-client
Michael Pflüger | 7 Jan 2004 23:52
Picon
Picon

Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

I have tried it with the current 2.6 cifs development kernel which 
includes the latest cifs, but i still have this problem.
ls -l displays the correcz sizes as i said, however, when i do ls -ls, 
the sizes in front of the filenames are far too small too (159K for a 
5MB file..)
As i already said, when i use smbfs to mount the share all this does not 
happen and sizes are reported correctly.
I hope a developer can tell me his opinion about it and if it can be fixed?

regards,
Michael
Luis Claudio R. Goncalves | 13 Jan 2004 18:48
Picon
Favicon

Re: Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

Hi!

I've been trying to reproduce the problem you're facing and had no success
at all. I've tested it with cifs 0.99a, samba 3.0.1 and kernel 2.4.23-benh1
(ibook) and 2.4.22+patches (i386).

Could you please describe your test environment and send me an strace log for
a "ls -l" with smbfs and another one for cifs? I'm quite curious...

On Wed, Jan 07, 2004 at 11:52:20PM +0100, Michael Pflüger wrote:
| I have tried it with the current 2.6 cifs development kernel which 
| includes the latest cifs, but i still have this problem.
| ls -l displays the correcz sizes as i said, however, when i do ls -ls, 
| the sizes in front of the filenames are far too small too (159K for a 
| 5MB file..)
| As i already said, when i use smbfs to mount the share all this does not 
| happen and sizes are reported correctly.
| I hope a developer can tell me his opinion about it and if it can be fixed?

Regards,
Luis
--

-- 
[ Luis Claudio R. Goncalves                  lclaudio <at> conectiva.com.br ]
[ Fingerprint:   4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8    ]
[ Msc has come!!!! - Conectiva HA Team - Gospel User - Linuxer - !Java ]
[ Fault Tolerance - Real-Time - Distributed Systems - IECLB - IS 40:31 ]
[ LateNite Programmer        --  My Utmost for His Highest  --         ]
Michael Pflüger | 13 Jan 2004 19:47
Picon
Picon

Re: Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

well, the differences i see, i was using a 2.6 kernel as i said, and the 
shares are on a Windows XP SP1 box, i havent tried connecting to a samba 
server with cifs as i dont need this as of yet, most PCs run still 
windows in our home network..
I've got another Linux box with kernel 2.4, i could install cifs and try 
it there too..
Here are the straces on the 2.6 System:
http://empx.dyndns.org/strace_cifs.txt
http://empx.dyndns.org/strace_smbfs.txt
The file is 526K as ls -s reports correctly with smbfs, yet with cifs it 
says 17K..
Hope this helps

Mike

>Hi!
>
>I've been trying to reproduce the problem you're facing and had no success
>at all. I've tested it with cifs 0.99a, samba 3.0.1 and kernel 2.4.23-benh1
>(ibook) and 2.4.22+patches (i386).
>
>Could you please describe your test environment and send me an strace log for
>a "ls -l" with smbfs and another one for cifs? I'm quite curious...
>
>On Wed, Jan 07, 2004 at 11:52:20PM +0100, Michael Pflüger wrote:
>| I have tried it with the current 2.6 cifs development kernel which 
>| includes the latest cifs, but i still have this problem.
>| ls -l displays the correcz sizes as i said, however, when i do ls -ls, 
>| the sizes in front of the filenames are far too small too (159K for a 
>| 5MB file..)
>| As i already said, when i use smbfs to mount the share all this does not 
>| happen and sizes are reported correctly.
>| I hope a developer can tell me his opinion about it and if it can be fixed?
>
>Regards,
>Luis
>  
>
Luis Claudio R. Goncalves | 13 Jan 2004 20:10
Picon
Favicon

Re: Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

Hi!

Reading both traces, the only difference lies on the very end of both
files, the write portion. Notice that not only the file sizes but also the
file rights are different... and the one reported by cifs is a bit weird.

http://empx.dyndns.org/strace_cifs.txt

fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401b0000
write(1, " 17K -rwxrwSrwt    1 root     ro"..., 101) = 101

http://empx.dyndns.org/strace_smbfs.txt

fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x401b0000
write(1, "526K -rwxr--r--    1 root     ro"..., 101) = 101

Mike, two questions: are you using the same mount options for both smbfs
and cifs? Are you using the binary version of mount.cifs from the website
or have you compiled it from the sources?

[]'s
Luis

On Tue, Jan 13, 2004 at 07:47:09PM +0100, Michael Pflüger wrote:
| well, the differences i see, i was using a 2.6 kernel as i said, and the 
| shares are on a Windows XP SP1 box, i havent tried connecting to a samba 
| server with cifs as i dont need this as of yet, most PCs run still 
| windows in our home network..
| I've got another Linux box with kernel 2.4, i could install cifs and try 
| it there too..
| Here are the straces on the 2.6 System:
| http://empx.dyndns.org/strace_cifs.txt
| http://empx.dyndns.org/strace_smbfs.txt
| The file is 526K as ls -s reports correctly with smbfs, yet with cifs it 
| says 17K..
| Hope this helps
| 
| Mike
| 
| >Hi!
| >
| >I've been trying to reproduce the problem you're facing and had no success
| >at all. I've tested it with cifs 0.99a, samba 3.0.1 and kernel 2.4.23-benh1
| >(ibook) and 2.4.22+patches (i386).
| >
| >Could you please describe your test environment and send me an strace log 
| >for
| >a "ls -l" with smbfs and another one for cifs? I'm quite curious...
| >
| >On Wed, Jan 07, 2004 at 11:52:20PM +0100, Michael Pflüger wrote:
| >| I have tried it with the current 2.6 cifs development kernel which 
| >| includes the latest cifs, but i still have this problem.
| >| ls -l displays the correcz sizes as i said, however, when i do ls -ls, 
| >| the sizes in front of the filenames are far too small too (159K for a 
| >| 5MB file..)
| >| As i already said, when i use smbfs to mount the share all this does not 
| >| happen and sizes are reported correctly.
| >| I hope a developer can tell me his opinion about it and if it can be 
| >fixed?
| >
| >Regards,
| >Luis
| > 
| >
---end quoted text---

--

-- 
[ Luis Claudio R. Goncalves                  lclaudio <at> conectiva.com.br ]
[ Fingerprint:   4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8    ]
[ Msc has come!!!! - Conectiva HA Team - Gospel User - Linuxer - !Java ]
[ Fault Tolerance - Real-Time - Distributed Systems - IECLB - IS 40:31 ]
[ LateNite Programmer        --  My Utmost for His Highest  --         ]
Mike | 13 Jan 2004 21:05
Picon
Picon

Re: Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

Well, i'm using no mount options at all besides -t cifs/smbfs and -o 
user=xxx,pass=yyy
I've used the version that came with samba, now i've also tried the 
binary and the source one from the website, but all 3 behave in the same 
way.
Are your shares on a WinXP box too?

Michael

Luis Claudio R. Goncalves wrote:

>Hi!
>
>Reading both traces, the only difference lies on the very end of both
>files, the write portion. Notice that not only the file sizes but also the
>file rights are different... and the one reported by cifs is a bit weird.
>
>
>http://empx.dyndns.org/strace_cifs.txt
>
>fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
>mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x401b0000
>write(1, " 17K -rwxrwSrwt    1 root     ro"..., 101) = 101
>
>
>http://empx.dyndns.org/strace_smbfs.txt
>
>fstat64(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
>mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
>0x401b0000
>write(1, "526K -rwxr--r--    1 root     ro"..., 101) = 101
>
>
>Mike, two questions: are you using the same mount options for both smbfs
>and cifs? Are you using the binary version of mount.cifs from the website
>or have you compiled it from the sources?
>
>[]'s
>Luis
>  
>
Michael Pflüger | 14 Jan 2004 17:11
Picon
Picon

Re: Re: du reports wrong directory sizes on kernel 2.6(.1rc2) and cifs 0.9.4

I've cifs compiled into the kernel btw, not running as module.
And as i said, ls -s reports wrong sizes for all files, it's no special 
file.
ls -s displays not the actual size of a file but the space it uses on 
the disk/fielsystem, is that correct?
on my local partition it displays 4KB for a 1 Byte file, which seems to 
be correct then (i'm using reiserfs with -notail), however on my XP 
share which uses NTFS, a file uses at least 4K of space too on the disk, 
yet ls -s displays 512Byte instead for a 1 Byte file, though this 
happens with both cifs and smbfs.

Here are the log entries:
Mount:
Jan 14 16:58:55 [kernel]  fs/cifs/cifsfs.c: Devname: //192.168.0.1/D 
flags: 0
Jan 14 16:58:55 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 66
Jan 14 16:58:55 [kernel] | 0x00 0x00 0x00 0x3e 0xff 0x53 0x4d 0x42  |  _ 
_ _ > <FF> S M B
Jan 14 16:58:55 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 68
Jan 14 16:58:55 [kernel] | 0x00 0x00 0x00 0x40 0xff 0x53 0x4d 0x42  |  _ 
_ _  <at>  <FF> S M B
Jan 14 16:58:55 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 80
Jan 14 16:58:55 [kernel] | 0x00 0x00 0x00 0x4c 0xff 0x53 0x4d 0x42  |  _ 
_ _ L <FF> S M B
Jan 14 16:58:55 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 138
Jan 14 16:58:55 [kernel] | 0x00 0x00 0x00 0x86 0xff 0x53 0x4d 0x42  |  _ 
_ _ _ <FF> S M B

ls -shl file_on_share(again 526K file, ls -s reports 17K):
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c: CIFS VFS: in cifs_lookup as 
Xid: 292025 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c:  parent inode = 0xc93623a4 name 
is: Abi and dentry = 0xcddd4c80
Jan 14 16:59:06 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 144
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  Old time 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  New time 91275122
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  Directory inode
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: leaving 
cifs_get_inode_info (xid = 292026) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c: CIFS VFS: leaving cifs_lookup 
(xid = 292025) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c: CIFS VFS: in cifs_lookup as 
Xid: 292027 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c:  parent inode = 0xc619f0a4 name 
is: phpbb_db_backup[1].sql.gz and dentry = 0xcddd4980
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c: In lookup nd flags 0x0 open 
intent flags 0x24
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c:  NULL inode in lookup
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c:  Full path: 
\Abi\phpbb_db_backup[1].sql.gz inode = 0x00000000
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: in 
cifs_get_inode_info as Xid: 292028 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: Getting info on 
\Abi\phpbb_db_backup[1].sql.gz
Jan 14 16:59:06 [kernel]  fs/cifs/cifssmb.c: In QPathInfo path 
\Abi\phpbb_db_backup[1].sql.gz
Jan 14 16:59:06 [kernel]  fs/cifs/transport.c: For smb_command 50
Jan 14 16:59:06 [kernel]  fs/cifs/transport.c: Sending smb of length 134
Jan 14 16:59:06 [kernel]  fs/cifs/connect.c: Peek length rcvd: 36 with 
smb length: 196
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  Old time 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  New time 91275125
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c:  File inode
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: leaving 
cifs_get_inode_info (xid = 292028) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/dir.c: CIFS VFS: leaving cifs_lookup 
(xid = 292027) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: in cifs_revalidate 
as Xid: 292029 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: Revalidate full path: 
\Abi\phpbb_db_backup[1].sql.gz for inode 0xc619f824 with count 1 dentry: 
0xcddd4980 d_time 91
275125 at time 91275125
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: leaving 
cifs_revalidate (xid = 292029) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: in cifs_revalidate 
as Xid: 292030 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: Revalidate full path: \Abi 
for inode 0xc619f0a4 with count 1 dentry: 0xcddd4c80 d_time 91275125 at 
time 91275125
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: leaving 
cifs_revalidate (xid = 292030) rc = 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: in cifs_revalidate 
as Xid: 292031 with uid: 0
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: Revalidate full path: 
\Abi\phpbb_db_backup[1].sql.gz for inode 0xc619f824 with count 1 dentry: 
0xcddd4980 d_time 91
275125 at time 91275125
Jan 14 16:59:06 [kernel]  fs/cifs/inode.c: CIFS VFS: leaving 
cifs_revalidate (xid = 292031) rc = 0

Luis Claudio R. Goncalves wrote:

>Hi again!
>
>I was trying to identify what was keeping me from reproducing the behavior
>you've observed... but so far I still can't reproduce it. I have no winXP
>box at home.
>
>Could you please do a last test and send the results to me and to Steven
>French? I need you to load the cifs module and run:
>
>        echo 1 > /proc/fs/cifs/cifsFYI
>        echo 1 > /proc/fs/cifs/traceSMB
>        
>Then you can mount the winXP share and just run du and ls on that file
>where you see the weird size report.
>
>All the log will be sent to syslog, and this is what I need.
>
>Thanks for your help and patience :)
>
>Luis
>  
>
Steven French | 16 Jan 2004 17:30
Picon
Favicon

Re: CIFS bug

> but the cifs module still is not able to copy large files (several hundred Mo) from my linux
> box to a W2K3 server. I have no problems to transfert "small" files.


Your log shows the tcp session died to the Windows 2003 server during the copy, and reconnection failed. A theory I had been pursuing for an unrelated problem earlier was that in 2.6 the demultiplex thread which handles the receives & demultiplexing of the tcp data from the server may get hung (forever) in the Linux tcp stack (it should timeout within a few seconds and reconnect based on the socket options I set), but a more likely theory based on the error in SessionSetup that was reported in the log (and the lack of a reported error on the preceding frame - the SMB NegotiateProtocol requeest) is that the password or user or domain information that I am using to reconnect your session is incorrect since these are the only interesting pieces of information that I send on the SMB Session Setup request and they are sent from data saved in the cifs session structure (which /proc/fs/cifs/DebugData will partially dump out). After those failed reconnection attempts the write operations themselves failed which would be expected depending on the hard vs. soft mount option you chose at mount time. You can look at /proc/fs/cifs/DebugData to see if the Tcp Session is connected but the SMB Session is not or vice versa. I would expect that /proc/fs/cifs/DebugData would show a valid tcp session (which was succesfully reconnected by the corresponding "cifsd" kernel thread - you should check that that thread still exists and is running) but the smb session in disconnected state. The rc = 5 is presumably access denied (I will need to check when I get back to a computer with the source tree installed). I will try some experiments when I get back with Windows 2003 reconnection but the thing to look for in the network trace (or if the /proc/fs/cifs parm is enabled to trace cifs packets to the kernel log) are are that the userid & domain on the SMBSessionSetup during reconnection match the ones sent during the initial mount. Checking that the NTLM password hash matches is not easy to do but if the userid & domain match on the two sessionsetups and one fails - that leaves the less likely problem of an incorrectly saved NTLM password hash unless an obscure problem with cifs packet signing (which should not be an issue until the frame after SessionSetup completes so I discount that theory).

I don't have access to a Windows 2003 system here but I can try on Monday to see if this can be artificially generated e.g. by dropping the a cifs vfs mounted session to Windows 2003 by going to the server and doing "net session \\a.b.c.d /delete" (where a.b.c.d is your workstations ip address) and then retrying some cifs vfs operation such as ls or stat of the mounted directory from the client.


Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com

_______________________________________________
linux-cifs-client mailing list
linux-cifs-client <at> lists.samba.org
http://lists.samba.org/mailman/listinfo/linux-cifs-client

Gmane