Custom Search
|
Date: October 31, 2005
From: Devon Harding <devonharding@xxxxxxxxx>
In-reply-to:
<1130504748.8883.3.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<2baac6140510220425r29673e4ejf45c1ef99d1c401d@xxxxxxxxxxxxxx> <2baac6140510280554y21b5bb6bn6af8bfa6b67bd3dc@xxxxxxxxxxxxxx> <1130504748.8883.3.camel@xxxxxxxxxxxxxxxxxxxxxxx>
On Fri, 2005-10-28 at 08:54 -0400, Devon Harding wrote:
> Anyone?
>
> On 10/22/05, Devon Harding <devonharding@xxxxxxxxx> wrote:
> How can I get cifs mount a mount point at boot up on FC3?
> After I boot up, I type 'mount' and the mount point is not
> showing. But when I type 'mount -a' then 'mount' again it
> shows. I think its trying to mount before smb is loaded.
> Here's is my /etc/fstab
>
> //neptune/share /share cifs
> credentials=/root/.cifsusers 0 0
>
> -Devon
I'm not an FC3 user, so this may not be accurate, but since nobody else
has answered...
In gentoo, there is an init script, /etc/init.d/netmount. It runs after
the network interface is brought up. Does FC3 have such a file, and is
it being run at startup?
--
David Kleikamp
IBM Linux Technology Center
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 28, 2005
From: MattSpam Bockol <spambockol@xxxxxxxxx>
In-reply-to:
<20051028153648.GA27710@xxxxxxxxxxxxxxxxxx>
References:
<1513c2cc0510280743l6812a375mdec6ab63fe0bc920@xxxxxxxxxxxxxx> <20051028153648.GA27710@xxxxxxxxxxxxxxxxxx>
Hi, Matt.
I haven't looked into the problem you're reporting but I can tell you that
I am using the CIFS-VFS with Novell's CIFS server. I haven't had any
serious problems (except that the server side seems to get stuck every now
and then and the admin-folk need to unload and reload the NLM).
I don't have time to dig further right now but I'll try to get Novell
version numbers for you. My clients are SuSEPro9.2 and 9.3 with 2.6
kernels.
Chris -)-----
...Carleton, eh? I'm at the UofMn.
On Fri, Oct 28, 2005 at 09:43:30AM -0500, MattSpam Bockol wrote:
> Hi Folks,
>
> I'm running RedHat Enterprise Linux AS 4 ( 2.6.9-22.ELsmp kernel ) and
> trying to connect to a Netware 6.5 service pack 2 server via CIFS with
> limited success. I've read elsewhere that Novell's CIFS implementation is
> not compatible with the Linux CIFS client, but I'm not sure how dated that
> information was. I can connect and navigate directories but I can't read
> files from the mount. Here's the dmesg when I try:
>
> fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 467 with uid: 0
> fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1
> dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153926716
> fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 467) rc = 0
> fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 468 with uid: 0
> fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1
> dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153926716
> fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 468) rc = 0
> fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 469 with uid: 0
> fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1
> dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153927189
> fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 469) rc = 0
> fs/cifs/file.c: CIFS VFS: in cifs_open as Xid: 470 with uid: 0
> fs/cifs/file.c: inode = 0xcc181c30 file flags are 0x8000 for \Courses\net-
> map.bat
> fs/cifs/transport.c: For smb_command 162
> fs/cifs/transport.c: Sending smb of length 126
> fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x6e)
> fs/cifs/connect.c: Mid 0x50 matched - waking up
> fs/cifs/file.c: inode unchanged on server
> fs/cifs/inode.c: Getting info on \Courses\net-map.bat
> fs/cifs/inode.c: Old time 1153926716
> fs/cifs/inode.c: New time 1153927196
> fs/cifs/inode.c: File inode
> fs/cifs/file.c: CIFS VFS: leaving cifs_open (xid = 470) rc = 0
> fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 471 with uid: 0
> fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1
> dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153927196
> fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 471) rc = 0
> fs/cifs/cifsfs.c: In read_wrapper size 16384 at 0
> fs/cifs/file.c: CIFS VFS: in cifs_readpages as Xid: 472 with uid: 0
> fs/cifs/transport.c: For smb_command 46
> fs/cifs/transport.c: Sending smb of length 59
> fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x27)
> fs/cifs/connect.c: Mid 0x51 matched - waking up
> fs/cifs/netmisc.c: !!Mapping smb error code 5 to POSIX err -13 !!
> CIFS VFS: Send error in read = -13
>
> It would be good to know if Netware was responsible, if it's been fixed in
> newer kernels (or Netware versions) or if there's anyone here willing to
> look into the problem (I'm not a kernel hacker, but I can do all sorts of
> testing), or if I'm barking up the wrong tree. I was mounting via smbfs
> originally, but on several 2.6 kernels (really, every one that I tried) the
> module would oops under load, crash the system, take down my webserver and
> much suffering would ensue. Trying to figure out a fix for smbfs, everyone
> directed me toward CIFS. :)
>
> Thanks,
> Matt Bockol
> Web Technical Administrator
> Carleton College
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client@xxxxxxxxxxxxxxx
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
--
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel
jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq.
ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx
OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 28, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051028153648.GA27710@xxxxxxxxxxxxxxxxxx>
References:
<20051028153648.GA27710@xxxxxxxxxxxxxxxxxx>
The server returning access denied on read is a little unusual, but perhaps this server version did not support 64 bit offsets (cifs vfs added support for older style 32 bit read/write offset after the version shipped with RHEL4 and its service packs).
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@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 28, 2005
From: "Christopher R. Hertel" <crh@xxxxxxxxxxxx>
In-reply-to:
<1513c2cc0510280743l6812a375mdec6ab63fe0bc920@xxxxxxxxxxxxxx>
References:
<1513c2cc0510280743l6812a375mdec6ab63fe0bc920@xxxxxxxxxxxxxx>
Hi, Matt. I haven't looked into the problem you're reporting but I can tell you that I am using the CIFS-VFS with Novell's CIFS server. I haven't had any serious problems (except that the server side seems to get stuck every now and then and the admin-folk need to unload and reload the NLM). I don't have time to dig further right now but I'll try to get Novell version numbers for you. My clients are SuSEPro9.2 and 9.3 with 2.6 kernels. Chris -)----- ...Carleton, eh? I'm at the UofMn. On Fri, Oct 28, 2005 at 09:43:30AM -0500, MattSpam Bockol wrote: > Hi Folks, > > I'm running RedHat Enterprise Linux AS 4 ( 2.6.9-22.ELsmp kernel ) and > trying to connect to a Netware 6.5 service pack 2 server via CIFS with > limited success. I've read elsewhere that Novell's CIFS implementation is > not compatible with the Linux CIFS client, but I'm not sure how dated that > information was. I can connect and navigate directories but I can't read > files from the mount. Here's the dmesg when I try: > > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 467 with uid: 0 > fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1 > dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153926716 > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 467) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 468 with uid: 0 > fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1 > dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153926716 > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 468) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 469 with uid: 0 > fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1 > dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153927189 > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 469) rc = 0 > fs/cifs/file.c: CIFS VFS: in cifs_open as Xid: 470 with uid: 0 > fs/cifs/file.c: inode = 0xcc181c30 file flags are 0x8000 for \Courses\net- > map.bat > fs/cifs/transport.c: For smb_command 162 > fs/cifs/transport.c: Sending smb of length 126 > fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x6e) > fs/cifs/connect.c: Mid 0x50 matched - waking up > fs/cifs/file.c: inode unchanged on server > fs/cifs/inode.c: Getting info on \Courses\net-map.bat > fs/cifs/inode.c: Old time 1153926716 > fs/cifs/inode.c: New time 1153927196 > fs/cifs/inode.c: File inode > fs/cifs/file.c: CIFS VFS: leaving cifs_open (xid = 470) rc = 0 > fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 471 with uid: 0 > fs/cifs/inode.c: Revalidate: \Courses\net-map.bat inode 0xcc181c30 count 1 > dentry: 0xed5a3e8c d_time 1153926716 jiffies 1153927196 > fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 471) rc = 0 > fs/cifs/cifsfs.c: In read_wrapper size 16384 at 0 > fs/cifs/file.c: CIFS VFS: in cifs_readpages as Xid: 472 with uid: 0 > fs/cifs/transport.c: For smb_command 46 > fs/cifs/transport.c: Sending smb of length 59 > fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x27) > fs/cifs/connect.c: Mid 0x51 matched - waking up > fs/cifs/netmisc.c: !!Mapping smb error code 5 to POSIX err -13 !! > CIFS VFS: Send error in read = -13 > > It would be good to know if Netware was responsible, if it's been fixed in > newer kernels (or Netware versions) or if there's anyone here willing to > look into the problem (I'm not a kernel hacker, but I can do all sorts of > testing), or if I'm barking up the wrong tree. I was mounting via smbfs > originally, but on several 2.6 kernels (really, every one that I tried) the > module would oops under load, crash the system, take down my webserver and > much suffering would ensue. Trying to figure out a fix for smbfs, everyone > directed me toward CIFS. :) > > Thanks, > Matt Bockol > Web Technical Administrator > Carleton College > _______________________________________________ > linux-cifs-client mailing list > linux-cifs-client@xxxxxxxxxxxxxxx > https://lists.samba.org/mailman/listinfo/linux-cifs-client -- "Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X Samba Team -- http://www.samba.org/ -)----- Christopher R. Hertel jCIFS Team -- http://jcifs.samba.org/ -)----- ubiqx development, uninq. ubiqx Team -- http://www.ubiqx.org/ -)----- crh@xxxxxxxxxxxx OnLineBook -- http://ubiqx.org/cifs/ -)----- crh@xxxxxxxxx
Date: October 28, 2005
From: Lars Müller <lmuelle@xxxxxxx>
In-reply-to:
<2baac6140510280554y21b5bb6bn6af8bfa6b67bd3dc@xxxxxxxxxxxxxx>
References:
<2baac6140510220425r29673e4ejf45c1ef99d1c401d@xxxxxxxxxxxxxx> <2baac6140510280554y21b5bb6bn6af8bfa6b67bd3dc@xxxxxxxxxxxxxx>
On Fri, Oct 28, 2005 at 08:54:43AM -0400, Devon Harding wrote: > > On 10/22/05, Devon Harding <devonharding@xxxxxxxxx> wrote: > > > > How can I get cifs mount a mount point at boot up on FC3? After I boot up, > > I type 'mount' and the mount point is not showing. But when I type 'mount > > -a' then 'mount' again it shows. I think its trying to mount before smb is > > loaded. Here's is my /etc/fstab > > > > //neptune/share /share cifs credentials=/root/.cifsusers 0 0 SuSE uses /etc/samba/smbfstab and an extra smbfs init script which handles smbfs and cifs mounts. These are excluded from the init script which does the usual mount. This allows us to add credential information to /etc/samba/smbfstab which is by default only readable by the root user. But in general I also like the gentoo approach Dave mentioned in his answer. Should we work on unifying this accros the Linux vendors? Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SuSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
pgpLdo4QLQBb3.pgp
Description: PGP signature
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 28, 2005
From: MattSpam Bockol <spambockol@xxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 28, 2005
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
In-reply-to:
<2baac6140510280554y21b5bb6bn6af8bfa6b67bd3dc@xxxxxxxxxxxxxx>
References:
<2baac6140510220425r29673e4ejf45c1ef99d1c401d@xxxxxxxxxxxxxx> <2baac6140510280554y21b5bb6bn6af8bfa6b67bd3dc@xxxxxxxxxxxxxx>
On Fri, 2005-10-28 at 08:54 -0400, Devon Harding wrote: > Anyone? > > On 10/22/05, Devon Harding <devonharding@xxxxxxxxx> wrote: > How can I get cifs mount a mount point at boot up on FC3? > After I boot up, I type 'mount' and the mount point is not > showing. But when I type 'mount -a' then 'mount' again it > shows. I think its trying to mount before smb is loaded. > Here's is my /etc/fstab > > //neptune/share /share cifs > credentials=/root/.cifsusers 0 0 > > -Devon I'm not an FC3 user, so this may not be accurate, but since nobody else has answered... In gentoo, there is an init script, /etc/init.d/netmount. It runs after the network interface is brought up. Does FC3 have such a file, and is it being run at startup? -- David Kleikamp IBM Linux Technology Center
Date: October 28, 2005
From: Devon Harding <devonharding@xxxxxxxxx>
In-reply-to:
<2baac6140510220425r29673e4ejf45c1ef99d1c401d@xxxxxxxxxxxxxx>
References:
<2baac6140510220425r29673e4ejf45c1ef99d1c401d@xxxxxxxxxxxxxx>
How can I get cifs mount a mount point at boot up on FC3? After I boot up, I type 'mount' and the mount point is not showing. But when I type 'mount -a' then 'mount' again it shows. I think its trying to mount before smb is loaded. Here's is my /etc/fstab
//neptune/share /share cifs credentials=/root/.cifsusers 0 0
-Devon
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 27, 2005
From: Howard Butler <hobu@xxxxxxxxxxx>
All,I'm having trouble with a CIFS mount using RHEL4. Here is kernel and cifs info:
[root@kenyon cifs]# /sbin/mount.cifs -V mount.cifs version: 1.5 [root@kenyon cifs]# uname -r 2.6.9-22.EL
/etc/fstab entry:
//XXX.XXX.XXX.XXX/cssmWorking /network cifs credentials=/etc/cred,auto,owner,uid=500,gid=501,dir_mode=0775,file_mode=0644,domain=IASTATE.EDU 0 0
Mounting works ok, and I can create and remove directories from the mount, but when I try to read a file (or touch an empty one, like "touch /network/foo" in this example), an Input/Ouput error is raised and NT_STATUS_ILLEGAL_CHARACTER is given in the logs. Reading through the archives, I found out how to turn on cifsFYI and DebugData, which puts more info in dmesg. Relevant information from dmesg showing the mount and the attempt to touch the file in the mount is below. The mount is against an ONStor NAS gateway which is a member of the IASTATE domain and works perfectly well with our windows clients.
Another bit of information is that I can use smbclient to read files (have not tried creating them). I have been unable to mount it with smbmount (all kinds of access denied messages no matter how much list advice I follow and how many permutations I try).
fs/cifs/connect.c: CIFS VFS: in cifs_mount as Xid: 176 with uid: 0 fs/cifs/connect.c: Domain name set fs/cifs/connect.c: Username: hobu fs/cifs/connect.c: UNC: \\xxx.xxx.xxx.xxx\cssmWorking ip: xxx.xxx.xxx.xxx fs/cifs/connect.c: Socket created fs/cifs/connect.c: Existing smb sess not found fs/cifs/transport.c: For smb_command 114 fs/cifs/transport.c: Sending smb of length 47 fs/cifs/connect.c: Demultiplex PID: 24407 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x61) fs/cifs/connect.c: Mid 0x65 matched - waking up fs/cifs/connect.c: Security Mode: 0x3 Capabilities: 0x33fc Time Zone: 0 fs/cifs/connect.c: In sesssetup fs/cifs/transport.c: For smb_command 115 fs/cifs/transport.c: Sending smb of length 224 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x8a) fs/cifs/connect.c: Mid 0x66 matched - waking up fs/cifs/connect.c: UID = 1 fs/cifs/connect.c: CIFS Session Established successfully fs/cifs/connect.c: file mode: 0x1a4 dir mode: 0x1fd fs/cifs/transport.c: For smb_command 117 fs/cifs/transport.c: Sending smb of length 104 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x42) fs/cifs/connect.c: Mid 0x67 matched - waking up fs/cifs/connect.c: Tcon flags: 0x1 fs/cifs/connect.c: CIFS Tcon rc = 0 fs/cifs/cifssmb.c: In QFSDeviceInfo fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb of length 68 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x44) fs/cifs/connect.c: Mid 0x68 matched - waking up fs/cifs/cifssmb.c: In QFSAttributeInfo fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb of length 68 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x50) fs/cifs/connect.c: Mid 0x69 matched - waking up fs/cifs/connect.c: CIFS VFS: leaving cifs_mount (xid = 176) rc = 0 fs/cifs/inode.c: CIFS VFS: in cifs_read_inode as Xid: 177 with uid: 0 fs/cifs/inode.c: Getting info on fs/cifs/cifssmb.c: In QPathInfo path fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb of length 74 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x9e) fs/cifs/connect.c: Mid 0x6a matched - waking up fs/cifs/inode.c: Old time 0 fs/cifs/inode.c: New time 6973098 fs/cifs/inode.c: Directory inode fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 178 with uid: 500fs/cifs/inode.c: Revalidate: inode 0xe4b3cd34 count 1 dentry: 0xf7831ac8 d_time 0 jiffies 6973100
fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 178) rc = 0 fs/cifs/inode.c: CIFS VFS: in cifs_revalidate as Xid: 179 with uid: 0fs/cifs/inode.c: Revalidate: inode 0xe4b3cd34 count 1 dentry: 0xf7831ac8 d_time 0 jiffies 6994103
fs/cifs/inode.c: Getting info on fs/cifs/cifssmb.c: In QPathInfo path fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb of length 74 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x9e) fs/cifs/connect.c: Mid 0x6b matched - waking up fs/cifs/inode.c: Old time 6973098 fs/cifs/inode.c: New time 6994104 fs/cifs/inode.c: Directory inode fs/cifs/inode.c: cifs_revalidate - inode unchanged fs/cifs/inode.c: CIFS VFS: leaving cifs_revalidate (xid = 179) rc = 0 fs/cifs/dir.c: CIFS VFS: in cifs_lookup as Xid: 180 with uid: 0fs/cifs/dir.c: parent inode = 0xe4b3cd34 name is: foo and dentry = 0xf7831630
fs/cifs/dir.c: In lookup nd flags 0x300 open intent flags 0x8942 fs/cifs/dir.c: NULL inode in lookup fs/cifs/dir.c: Full path: \foo inode = 0x00000000 fs/cifs/inode.c: Getting info on \foo fs/cifs/cifssmb.c: In QPathInfo path \foo fs/cifs/transport.c: For smb_command 50 fs/cifs/transport.c: Sending smb of length 82 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x27) fs/cifs/connect.c: Mid 0x6c matched - waking up Status code returned 0xc0000034 NT_STATUS_OBJECT_NAME_NOT_FOUND fs/cifs/netmisc.c: !!Mapping smb error code 2 to POSIX err -2 !! fs/cifs/cifssmb.c: Send error in QPathInfo = -2 fs/cifs/dir.c: CIFS VFS: leaving cifs_lookup (xid = 180) rc = 0 fs/cifs/dir.c: CIFS VFS: in cifs_create as Xid: 181 with uid: 0 fs/cifs/transport.c: For smb_command 162 fs/cifs/transport.c: Sending smb of length 94 fs/cifs/connect.c: Peek length rcvd: 0x24 beginning 0x27) fs/cifs/connect.c: Mid 0x6d matched - waking up Status code returned 0xc0000161 NT_STATUS_ILLEGAL_CHARACTER fs/cifs/netmisc.c: !!Mapping smb error code 31 to POSIX err -5 !! fs/cifs/cifssmb.c: Error in Open = -5 fs/cifs/dir.c: cifs_create returned 0xfffffffb fs/cifs/dir.c: CIFS VFS: leaving cifs_create (xid = 181) rc = -5 Any ideas?Howard
Date: October 27, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<43604D05.8060801@xxxxxxxxxx>
References:
<43604D05.8060801@xxxxxxxxxx>
objdump (IIRC "objdump -S fs/cifs/cifsfs.o" for this function would be close to the right syntax) allows you to view intermixed source and assembler output to more accurately find the exact location of an oops.
Due to the delays in getting mainline 2.6.14 out there are a relatively large amount of code changes (mostly fixes but some big performance improvements) in cifs since 2.6.13 that are backed up on the imminent release of 2.6.14 ie fixes in cifs version 1.39 and in -mm but not in mainline yet. But that is a long shot - I suspect that this is more a memory management issue - not something that cifs directly corrupted. There is only the change in timing for the oplock thread (there was a sleep in the wrong location) that comes to mind and a race between write and close that seem like they would possibly be related. If you are comfortable building a module - in particular trying 1.39 cifs - while this analysis is going on - that would of course be useful if it fixed the problem or changed the problem.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Ian Berry <iberry@xxxxxxxxxx>
10/26/2005 10:44 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 27, 2005
From: Ian Berry <iberry@xxxxxxxxxx>
In-reply-to:
<OFE0063836.2CB9C7A0-ON872570A7.000DAB58-862570A7.000E88F1@xxxxxxxxxx>
References:
<OFE0063836.2CB9C7A0-ON872570A7.000DAB58-862570A7.000E88F1@xxxxxxxxxx>
Steven French wrote:
I am interested in exploring this bug more (I want to take a look at that location in objdump and see if it is oopsing on a null page in the mapping or not) - and I would like it if you could open a bugzilla entry (bugzilla.samba.org or against the osdl kernel bugzilla) so we don't lose this issue - even if it turns out to not be a cifs problem.
Thanks for your interest in this bug, I really appreciate it. This one is going to be interesting on my side to debug since the these problems are actually occurring on customer servers that are maintained by me. I do not think it will be a problem coordinating with them though. Otherwise, I am more than willing to set this up in a lab environment using the same software.
Let me know what I can do to get you an objdump, I have not played with it before. I submitted bug#3219 to the Samba bugzilla so this can be tracked further.
Thanks again, Ian
Date: October 27, 2005
From: Andrew Morton <akpm@xxxxxxxx>
In-reply-to:
<OFE0063836.2CB9C7A0-ON872570A7.000DAB58-862570A7.000E88F1@xxxxxxxxxx>
References:
<20051026173059.39e0f106.akpm@xxxxxxxx> <OFE0063836.2CB9C7A0-ON872570A7.000DAB58-862570A7.000E88F1@xxxxxxxxxx>
(Adds Ian to cc) Steven French <sfrench@xxxxxxxxxx> wrote: > > > > > > > >Call Trace: > > [<c013fc03>] find_get_pages+0x53/0x60 > > [<c014a16e>] pagevec_lookup+0x2e/0x40 > > [<c014a6e9>] invalidate_mapping_pages+0x59/0x100 > > [<c022ce5b>] CIFSSMBLock+0x7b/0x1e0 > > [<c022b452>] cifs_oplock_thread+0x112/0x214 > > Ian, > I just saw your post on lkml about the invalidate_mapping_pages oops > (above) in the cifs oplock thread. The reference in the cifs code to > locking improvements, was not a reference to oplock (client caching tokens) > but to byte range locking (which is difficult to map from POSIX advisory > style to mandatory CIFS style locks, and for which the Samba team, > including myself, and others are working on network protocol extensions to > circumvent, there are two byte range locking changes, unrelated to your > issue which need to be addressed in code and are reasonably well understood > - special handling for whole file unlock (0 to MAX_OFFSET) and replay of > byte range lock state after session failure and auto-reconnection. Neither > of these have anything to do with your report. > > The cifs code that presumably is triggerring this is pretty harmless > looking > invalidate_remote_inode(inode); > and presumably the oops is due to a problem with some of the pages in the > mapping of this inode which is not something I have seen before. > > I am interested in exploring this bug more (I want to take a look at that > location in objdump and see if it is oopsing on a null page in the mapping > or not) - and I would like it if you could open a bugzilla entry > (bugzilla.samba.org or against the osdl kernel bugzilla) so we don't lose > this issue - even if it turns out to not be a cifs problem. > > > > > Steve French > Senior Software Engineer > Linux Technology Center - IBM Austin > phone: 512-838-2294 > email: sfrench at-sign us dot ibm dot com
Date: October 27, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051026173059.39e0f106.akpm@xxxxxxxx>
References:
<20051026173059.39e0f106.akpm@xxxxxxxx>
>Call Trace:
>
>
>
>
>
Ian,
I just saw your post on lkml about the invalidate_mapping_pages oops (above) in the cifs oplock thread. The reference in the cifs code to locking improvements, was not a reference to oplock (client caching tokens) but to byte range locking (which is difficult to map from POSIX advisory style to mandatory CIFS style locks, and for which the Samba team, including myself, and others are working on network protocol extensions to circumvent, there are two byte range locking changes, unrelated to your issue which need to be addressed in code and are reasonably well understood - special handling for whole file unlock (0 to MAX_OFFSET) and replay of byte range lock state after session failure and auto-reconnection. Neither of these have anything to do with your report.
The cifs code that presumably is triggerring this is pretty harmless looking
invalidate_remote_inode(inode);
and presumably the oops is due to a problem with some of the pages in the mapping of this inode which is not something I have seen before.
I am interested in exploring this bug more (I want to take a look at that location in objdump and see if it is oopsing on a null page in the mapping or not) - and I would like it if you could open a bugzilla entry (bugzilla.samba.org or against the osdl kernel bugzilla) so we don't lose this issue - even if it turns out to not be a cifs problem.
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@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 25, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<1130278749.26176.2.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<1130278749.26176.2.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Your trace shows the byte count is three bytes off (three bytes early) in the first smb (negotiate protocol) request that the cifs client sent. The code looks right - but we may be seeing a problem here with the compiler recognizing the packing of nested structures due to its alignment requirement. Note that these few fields in the protocol itself - in the smb header are not aligned. Presumably the issue is one or more of compiler confusion:
- with pragma pack (1) (although it handles it earlier in the writing to the smb_header)
- inside a typedef struct
- in a nested struct
may be confusing the compiler on arm - might be helpful to get a listing ie
make fs/cifs/cifssmb.s
and/or
objdump -S cifssmb.o
Could you forward those to me?
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@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 25, 2005
From: Joe butane <joebutane@xxxxxxxxx>
hi
Can we use Trans2 Set Path Info to change the file
attributes on W2K and above server OS's? I was unable
to capture any packets with this SMB command. i have
checked W2K to W2k and also samba to W2K capture.
Does anyone have any idea ab't this?
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com
Date: October 22, 2005
From: Devon Harding <devonharding@xxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 21, 2005
From: Steve French <smfrench@xxxxxxxxxxxxx>
Date: October 21, 2005
From: Steve French <smfltc@xxxxxxxxxx>
Are you running arm bigendian or little endian (apparently they can be configured either way)?
Please turn on smb tracing (or send a binary tcpdump or ethereal trace file):
echo 1 > /proc/fs/cifs/traceSMBso I can see what I sent on the wire in the negotiate protocol request (the response you show from the server looks like it rejected the offerred dialects - as it might if the server were pre-NT4 - such as OS/2 or DOS server). Assuming that your server is more recent than 1995, then I expect that what was sent from the client in the SMB negotiate protocol request (the first SMB) is what we need to look at - which is why I would like you to turn on the traceSMB setting.
In addition, it would be helpful to reenable the length check (roughly line 424 of fs/cifs/misc.c) and make it log all the time (cERROR) rather than only when debug messages (/proc/fs/cifs/cifsFYI) are enabled by changing the line from:
cFYI(0,
("Entering checkSMB with Length: %x, smb_buf_length: %x ",
length, len));
to
cERROR(1,
("Entering checkSMB with Length: %x, smb_buf_length: %x ",
length, len));
It would not hurt to turn on cifs debugging ("echo 7 >
/proc/fs/cifs/cifsFYI)") before the mount (which will allow more
information to be dumped).
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<OFC2756CC2.9F58585F-ON872570A0.00615DE8-862570A0.00635DB5@LocalDomain>
References:
<OFC2756CC2.9F58585F-ON872570A0.00615DE8-862570A0.00635DB5@LocalDomain>
Forgot to mention to enable logging of this slow response message, you also have to enable it at runtime
echo 4 > /proc/fs/cifs/cifsFYI
(1 turns on informational cifs messages, 2 turns on bad return code logging and 4 turns on checks for responses over 1 second).
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Steven French/Austin/IBM
10/20/2005 01:10 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051020201821.GA31022@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20051020201821.GA31022@xxxxxxxxxxxxxxxxxxxxxxxx>
My guess is that cifs behavior is similar to Windows, although a little hard to prove due to differences in mounting and vfs operations.
Part of the problem testing this is that specifying the wrong (old) password can give you guest logon depending on server configuration.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Jeremy Allison <jra@xxxxxxxxx> wrote on 10/20/2005 03:18:21 PM:
> On Thu, Oct 20, 2005 at 03:17:14PM -0500, Steven French wrote:
> > > do you treat "bad user/password" specially
> > No - I am pretty sure that the retry would occur with cifsfs too not just
> > smbfs.
> >
> > I could make it configurable and/or change the default (not retry on those
> > SMB return codes unless set differently).
>
> Changing the default seems to be the right idea to me.
>
> > Do you know exactly which NT Status codes (and older smb errors) we are
> > talking about?
>
> Not offhand. I'm in the laptop gallery at the NAS conference
> at the moment so won't be able to test this out until tomorrow.
>
> Jeremy.
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 20, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<OFD7A593BE.653AD980-ON872570A0.006F3E07-862570A0.006EF3AF@xxxxxxxxxx>
References:
<20051020184510.GC31447@xxxxxxxxxxxxxxxxxxxxxxxx> <OFD7A593BE.653AD980-ON872570A0.006F3E07-862570A0.006EF3AF@xxxxxxxxxx>
On Thu, Oct 20, 2005 at 03:17:14PM -0500, Steven French wrote: > > do you treat "bad user/password" specially > No - I am pretty sure that the retry would occur with cifsfs too not just > smbfs. > > I could make it configurable and/or change the default (not retry on those > SMB return codes unless set differently). Changing the default seems to be the right idea to me. > Do you know exactly which NT Status codes (and older smb errors) we are > talking about? Not offhand. I'm in the laptop gallery at the NAS conference at the moment so won't be able to test this out until tomorrow. Jeremy.
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051020184510.GC31447@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20051020184510.GC31447@xxxxxxxxxxxxxxxxxxxxxxxx>
> do you treat "bad user/password" specially No - I am pretty sure that the retry would occur with cifsfs too not just smbfs. I could make it configurable and/or change the default (not retry on those SMB return codes unless set differently). Do you know exactly which NT Status codes (and older smb errors) we are talking about? Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com
Date: October 20, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<OFC2756CC2.9F58585F-ON872570A0.00615DE8-862570A0.00635DB5@xxxxxxxxxx>
References:
<OFC2756CC2.9F58585F-ON872570A0.00615DE8-862570A0.00635DB5@xxxxxxxxxx>
Steve,
I'm here at the NAS conference and a large customer (Intel)
said that they'd had a problem with CIFS on Linux (almost certainly
with smbfs, not sure about cifsfs) - an EMC person also reported the
same problem.
What happens is an automounter mounts a remote cifs drive from a
Windows box, eventually the inactivity timer unmounts the drive,
but the users credentials are still cached in the kernel.
The user then changes their password on the AD DC, and at a later
time a cron job or other activity causes the drive to be remounted.
The cached credentials are wrong of course, and so what happens is
the client keeps retrying the sessionsetup (getting password errors
each time of course) until the account gets locked out at the DC.
Does CIFSFS handle this - ie. do you treat "bad user/password"
specially and abort the retry ? I had a quick look in the code
but couldn't see that case being handled.
Let me know,
Cheers,
Jeremy.
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
Some of you may find this technique useful for finding out when the server
is sending slow responses under load - and on which requests.
I added the corresponding code in the Linux cifs client version 1.38 source
and tried to make it reasonably easy to enable for people doing performance
analysis of the client or server or network.
If the client is compiled with CONFIG_CIFS_STATS (one of the kernel
configure options in the cifs kconfig menu) and if you enable the
additional checks at compile time by e.g.
#define CONFIG_CIFS_STATS2
(e.g. at the beginning of a cifs header such as fs/cifs/cifsglob.h) then
the following extra information will be displayed in
/proc/fs/cifs/DebugData for each server you are mounted to:
1) the number of application threads "In Send" (ie requests that the
client is currently trying to write to the tcp socket) - if this number is
high then it indicates the tcp socket is not accepting data fast enough.
2) the number of application threads "In MaxReq Wait" if this number is
non-zero very often, you might consider increasing the "cifs_max_pending"
parm when you load the cifs module on the client (assuming your server,
like Samba, can handle more than the default, 50 simultaneous requests)
In addition there is new data that can appear in dmesg which I am finding
useful as I try to figure out what is causing Samba to respond a little
slower than I expected in loopback configurations.
With CONFIG_CIFS_STATS2 enabled, cifs will log a debug message when a
response to a cifs request takes longer than 1 second (locking requests are
not logged as it is ok for them to block on the server). The entry is
of the form
"CIFS slow rsp: cmd <smb command code> mid <smb multiplex id> A:
<time since request began on client>
S: <time since the socket write returned indicating that the
request was actually sent to the server>
R: <time since the response was received by the demultiplex
thread>
The times are expressed in jiffies (the standard kernel unit of time).
If A is large but S and R are not, that might indicated that the tcp stack
is having trouble sending the request (the write to tcp is slow, perhaps
problems with loss/retries on the network or slow link, or tcp buffers too
small or problems with the server not acking fast enough). If S is large
that indicates that the server is slow (the response is not arriving to
cifsd on the client fast enough) - this might indicate an overloaded server
disk. If R is large then the data got to the client but then could not be
delivered fast enough to the right application, perhaps because the client
is overloaded and the application that issued the file api is not getting
scheduled - and therefore the client cpu may be overloaded. If the 1
second threshold is too short (I hit this many times running dbench with 50
threads or more even from just one client to Samba 3) then it can be
changed by altering line 96 of fs/cifs/transport.c from HZ (one seconds
worth of jiffies) to a larger or smaller value.
If we use this in conjunction with server performance analysis we should be
able to optimize Samba better for the testcases like dbench, fstress etc.
which launch lots of threads on the client hitting the smb server at one
time.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051020154140.GC29494@linux
>
References:
<20051020154140.GC29494@linux
>
I don't use either the level (0x208) or the unix cap bit yet on the client (it is unlikely that other clients do either) - so reusing this bit comes down to what Samba (the server) does with it today - if no one (server) sets it - and we are using it for approximately the same purpose that it was created for - seems less confusing to reuse it. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com Jeremy Allison <jra@xxxxxxxxx> wrote on 10/20/2005 10:41:40 AM: > On Thu, Oct 20, 2005 at 10:41:21AM -0500, Steven French wrote: > > > > > Can you explain what you mean here ? > > Sorry to be cryptic, I did not have source in front of me at the time but > > wanted to remind people new to this topic about what was already defined. > > > > #define CIFS_UNIX_FCNTL_CAP 0x00000001 > > > > is one of the bits that can be returned by the 64 bit capability flags on > > QFSINFO FILE_SYSTEM_UNIX_INFO (It was defined in the original Unix > > extensions spec). Presumably the setfsinfo would set this. > > > > For those who had not been following this thread ... in addition to the > > capability bit, a year or so ago we reserved a FILEINFO/PATHINFO level for > > GET/SET of posix locks (as level 0x208) and made a stab at defining a > > CIFS_POSIX_LOCK structure. > > Ok thanks I see what you mean. The only problem I have with it > is I'm proposing to change the read/write semantics in this > case, so was wondering if the set should be of a differently > named bit. > > Jeremy.
Date: October 20, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<OF1B76B70B.C5A06B42-ON872570A0.00552DDA-862570A0.0055B226@xxxxxxxxxx>
References:
<20051020054013.GA29494@linux
> <OF1B76B70B.C5A06B42-ON872570A0.00552DDA-862570A0.0055B226@xxxxxxxxxx>
On Thu, Oct 20, 2005 at 10:41:21AM -0500, Steven French wrote: > > > Can you explain what you mean here ? > Sorry to be cryptic, I did not have source in front of me at the time but > wanted to remind people new to this topic about what was already defined. > > #define CIFS_UNIX_FCNTL_CAP 0x00000001 > > is one of the bits that can be returned by the 64 bit capability flags on > QFSINFO FILE_SYSTEM_UNIX_INFO (It was defined in the original Unix > extensions spec). Presumably the setfsinfo would set this. > > For those who had not been following this thread ... in addition to the > capability bit, a year or so ago we reserved a FILEINFO/PATHINFO level for > GET/SET of posix locks (as level 0x208) and made a stab at defining a > CIFS_POSIX_LOCK structure. Ok thanks I see what you mean. The only problem I have with it is I'm proposing to change the read/write semantics in this case, so was wondering if the set should be of a differently named bit. Jeremy.
Date: October 20, 2005
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<OFD06E50A0.C2B4371D-ON872570A0.0053A545-862570A0.005357A9@xxxxxxxxxx>
References:
<OFD06E50A0.C2B4371D-ON872570A0.0053A545-862570A0.005357A9@xxxxxxxxxx>
Steven French wrote:
>>maybe some __attribute__((packed)) are needed ...
>
> Perhaps, but that seems unlikely to me. The cifspdu.h (what actually gets
> sent on the wire) is already packed (line 312 of fs/cifs/cifspdu.h) unless
> there is some odd compiler problem on that architecture (ie not recognizing
> the pragma).
Hmm. Ok.
Any idea which debug output would be usefull?
Maybe (if your time permits) you could extend you're error messages so
they'd print something like
bla wrong <value> (expected 'FOO' but got 'BAR')
Then together with the dump of the header or packet one would easily
spot an alingment problem!
Thanks a million!
Steven Scholz
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051020054013.GA29494@linux
>
References:
<20051020054013.GA29494@linux
>
> Can you explain what you mean here ? Sorry to be cryptic, I did not have source in front of me at the time but wanted to remind people new to this topic about what was already defined. #define CIFS_UNIX_FCNTL_CAP 0x00000001 is one of the bits that can be returned by the 64 bit capability flags on QFSINFO FILE_SYSTEM_UNIX_INFO (It was defined in the original Unix extensions spec). Presumably the setfsinfo would set this. For those who had not been following this thread ... in addition to the capability bit, a year or so ago we reserved a FILEINFO/PATHINFO level for GET/SET of posix locks (as level 0x208) and made a stab at defining a CIFS_POSIX_LOCK structure. Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<435740CC.60503@xxxxxxxxxxxxx>
References:
<435740CC.60503@xxxxxxxxxxxxx>
> maybe some __attribute__((packed)) are needed ...
Perhaps, but that seems unlikely to me. The cifspdu.h (what actually gets sent on the wire) is already packed (line 312 of fs/cifs/cifspdu.h) unless there is some odd compiler problem on that architecture (ie not recognizing the pragma).
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@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 20, 2005
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<435740CC.60503@xxxxxxxxxxxxx>
References:
<OFC0EBF125.C82693F3-ON87257099.007D13A6-86257099.007CA958@xxxxxxxxxx> <434F54C4.5030009@xxxxxxxxxxxxx> <434F642B.4020003@xxxxxxxxxxxxx> <435740CC.60503@xxxxxxxxxxxxx>
Steven French, >>I still get: >> >> CIFS VFS: Length less than smb header size >> CIFS VFS: bad smb detected. Illegal length. mid=1 >>Bad SMB: : dump of 48 bytes of data at 0xc0994ea0 >> >> 00000025 424d53ff 00000072 80018000 % . . . ÿ S M B r . . . . . . . >> 00000000 00000000 00000000 01080000 . . . . . . . . . . . . . . . . >> 00010000 00ffff01 00000000 00000000 . . . . . ÿ ÿ . . . . . . . . . >> (zzzZZZZzzz) > ... > BTW has CIFS ever been used on a ARM platform? > Could there be alignment problems with data structures? > As you might know, ARM only does 32bit accesses. So maybe some _ > __attribute__((packed)) are needed ... For instance the struct smb_hdr! Maybe if we print out the "Illegal length" or something we can see more. -- Steven Scholz
Date: October 20, 2005
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<434F642B.4020003@xxxxxxxxxxxxx>
References:
<OFC0EBF125.C82693F3-ON87257099.007D13A6-86257099.007CA958@xxxxxxxxxx> <434F54C4.5030009@xxxxxxxxxxxxx> <434F642B.4020003@xxxxxxxxxxxxx>
Steven French, >>>I did run into the bad smb in response from some windows XP servers on byte >>>range lock response. >>> >>>MS was sending an SMB of length 3 bytes shorter than the RFC1001 length >>>would require. I relaxed the check in cifs 1.38 >> > I downloaded cifs-1.38.tar.gz and copied all the files into > <mykernel>/fs/cifs, recompiled the kernel using > > CONFIG_CIFS=y > CONFIG_CIFS_STATS=y > CONFIG_CIFS_XATTR=y > CONFIG_CIFS_POSIX=y > CONFIG_CIFS_EXPERIMENTAL=y > > But using > > ~ # mount -t cifs //10.0.2.10/test /mnt/smb -o user=scholz,guest > > I still get: > > CIFS VFS: Length less than smb header size > CIFS VFS: bad smb detected. Illegal length. mid=1 > Bad SMB: : dump of 48 bytes of data at 0xc0994ea0 > > 00000025 424d53ff 00000072 80018000 % . . . ÿ S M B r . . . . . . . > 00000000 00000000 00000000 01080000 . . . . . . . . . . . . . . . . > 00010000 00ffff01 00000000 00000000 . . . . . ÿ ÿ . . . . . . . . . > (zzzZZZZzzz) > CIFS VFS: No response for cmd 114 mid 1 > CIFS VFS: cifs_mount failed w/return code = -112 > mount: Mounting //10.0.2.10/test on /mnt/smb failed: Host is down Any news on this? Can I help by providing more denug output? BTW has CIFS ever been used on a ARM platform? Could there be alignment problems with data structures? As you might know, ARM only does 32bit accesses. So maybe some _ __attribute__((packed)) are needed ... -- Steven Scholz
Date: October 20, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<OFAB047537.57FDE62A-ON872570A0.000B0DBA-862570A0.000AAFC8@xxxxxxxxxx>
References:
<20051019224911.GA29595@xxxxxxxxxxxxxxxxxxxxxxxx> <OFAB047537.57FDE62A-ON872570A0.000B0DBA-862570A0.000AAFC8@xxxxxxxxxx>
On Wed, Oct 19, 2005 at 09:02:04PM -0500, Steven French wrote: > > Not sure if it was clear in the earlier dicussion but there is an existing > bit reserved for posix locking capability An existing bit where ? Can you explain what you mean here ? Jeremy.
Date: October 20, 2005
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20051019224911.GA29595@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20051019224911.GA29595@xxxxxxxxxxxxxxxxxxxxxxxx>
Not sure if it was clear in the earlier dicussion but there is an existing bit reserved for posix locking capability
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@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: October 19, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
In-reply-to:
<a0600201fbf7c7b2d50c3@[17.202.43.180]
>
References:
<20051019222705.GA29097@xxxxxxxxxxxxxxxxxxxxxxxx> <a0600201fbf7c7b2d50c3@[17.202.43.180]
>
On Wed, Oct 19, 2005 at 03:43:33PM -0700, conrad@xxxxxxx wrote: > Sounds good. > > If POSIX clients need to request special behavior like that, then do you > still need a distinct posix get/set lock trans2? A CIFS_UNIX_POSIX_CAP > could enable POSIX behavior (including the fcntl F_GETLK capability not > present in smb otw.) Yes I think we still need the POSIX get/set - if only to make explicit that these semantics are different from the Windows locking get/set. Jeremy.
Date: October 19, 2005
From: conrad@xxxxxxx
In-reply-to:
<20051019222705.GA29097@xxxxxxxxxxxxxxxxxxxxxxxx>
References:
<20051019222705.GA29097@xxxxxxxxxxxxxxxxxxxxxxxx>
At 3:27 PM -0700 10/19/05, Jeremy Allison wrote: >[This time sent with the right subject line, sorry. Jeremy] > >Ok, I've started to think about the semantics of CIFS POSIX >locks within Samba, and there are some interesting challenges. > >We're currently thinking of a "posix get/set" lock trans2 >UNIX smb call - so far so good (easy). It's obvious that >POSIX locks conflict at set time, but what I'm trying to >work out is how these should interact with Windows read/write >calls and Windows mandatory locks. > >The easiest thing to do is to map CIFS posix locks onto a >kind of Windows lock, with the added ability to split/merge >lock ranges, and to upgrade/downgrade lock types (as POSIX >allows). > >That way the Windows locks will automatically conflict, >which is what you want. You'd like a POSIX lock set by >a UNIX client to conflict with Windows locks - and vica >versa. You'd also like a read or write from a Windows >client to conflict with both POSIX and Windows locks >(as they do now). The interesting case is a read or >write from a UNIX client. > >You'd like these to conflict with Windows locks, as >that's current behaviour, but not to conflict with >POSIX locks, as that is POSIX behaviour. The problem >is the server needs to know if a read/write is a POSIX-style >read/write or a Windows one. > >I'm proposing that we use the same mechanism we used to >select case-sensitive pathname traversal for POSIX clients, >in that a POSIX client does a setfsinfo with a capability >of CIFS_UNIX_POSIX_READWRITE_CAP (this can be OR'ed in >to the same setfsinfo that selects the case sensitive >filenames) - once this is set then read/writes on this >tid will be done with POSIX semantics - eg. POSIX locks >will be ignored. Yes it's horrible, but no worse than >the case-sensitive select. Sounds good. If POSIX clients need to request special behavior like that, then do you still need a distinct posix get/set lock trans2? A CIFS_UNIX_POSIX_CAP could enable POSIX behavior (including the fcntl F_GETLK capability not present in smb otw.)
Date: October 19, 2005
From: Jeremy Allison <jra@xxxxxxxxx>
[This time sent with the right subject line, sorry. Jeremy] Ok, I've started to think about the semantics of CIFS POSIX locks within Samba, and there are some interesting challenges. We're currently thinking of a "posix get/set" lock trans2 UNIX smb call - so far so good (easy). It's obvious that POSIX locks conflict at set time, but what I'm trying to work out is how these should interact with Windows read/write calls and Windows mandatory locks. The easiest thing to do is to map CIFS posix locks onto a kind of Windows lock, with the added ability to split/merge lock ranges, and to upgrade/downgrade lock types (as POSIX allows). That way the Windows locks will automatically conflict, which is what you want. You'd like a POSIX lock set by a UNIX client to conflict with Windows locks - and vica versa. You'd also like a read or write from a Windows client to conflict with both POSIX and Windows locks (as they do now). The interesting case is a read or write from a UNIX client. You'd like these to conflict with Windows locks, as that's current behaviour, but not to conflict with POSIX locks, as that is POSIX behaviour. The problem is the server needs to know if a read/write is a POSIX-style read/write or a Windows one. I'm proposing that we use the same mechanism we used to select case-sensitive pathname traversal for POSIX clients, in that a POSIX client does a setfsinfo with a capability of CIFS_UNIX_POSIX_READWRITE_CAP (this can be OR'ed in to the same setfsinfo that selects the case sensitive filenames) - once this is set then read/writes on this tid will be done with POSIX semantics - eg. POSIX locks will be ignored. Yes it's horrible, but no worse than the case-sensitive select. Thoughts and comments welcome ! Jeremy.