Custom Search
|
Date: March 31, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<442D968B.5010306@xxxxxxxxxxxxxxxxxxxxx>
References:
<442D968B.5010306@xxxxxxxxxxxxxxxxxxxxx>
http://www.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commit;h=e9917a000fcc370408c8b7b83f2e85dba5fffbd4 has a link to the patch
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Sam Flory <Sam.Flory@xxxxxxxxxxxxxxxxxxxxx>
03/31/2006 02:52 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 31, 2006
From: Sam Flory <Sam.Flory@xxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<OFB5A4C3F7.60D3AF0E-ON87257142.0072D0FD-86257142.00728E86@xxxxxxxxxx>
References:
<OFB5A4C3F7.60D3AF0E-ON87257142.0072D0FD-86257142.00728E86@xxxxxxxxxx>
Steven French wrote: > Sam, > Have fix that seems to work - am cleaning it up a bit and will post to > cifs-2.6.git later this afternoon. Thanks shoot me an email I'll give it a shot.
Date: March 31, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<442D7012.3030209@xxxxxxxxxxxxxxxxxxxxx>
References:
<442D7012.3030209@xxxxxxxxxxxxxxxxxxxxx>
Sam,
Have fix that seems to work - am cleaning it up a bit and will post to cifs-2.6.git later this afternoon.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Sam Flory <Sam.Flory@xxxxxxxxxxxxxxxxxxxxx>
03/31/2006 12:08 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 31, 2006
From: Sam Flory <Sam.Flory@xxxxxxxxxxxxxxxxxxxxx>
In-reply-to:
<OFF50FAD2F.C7D247E2-ON87257142.0061599F-86257142.00619CE8@xxxxxxxxxx>
References:
<OFF50FAD2F.C7D247E2-ON87257142.0061599F-86257142.00619CE8@xxxxxxxxxx>
Steven French wrote: > You are correct - major bug if signing is turned on. I need to fix this > asap for signing to work - cifs_sign_smb2 (called from SendReceive2) is > not complete but SendReceive2 is needed in ever more paths (including > obviously now Read). I'd be more an happy to test patches to 1.42 (or whatever). Normally I'm running a (mostly) RHEL 4 errata kernel , but I can compile a kernel.org kernel if need be.
Date: March 31, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<442D67A6.2030002@xxxxxxxxxxxxxxxxxxxxx>
References:
<442D67A6.2030002@xxxxxxxxxxxxxxxxxxxxx>
You are correct - major bug if signing is turned on. I need to fix this asap for signing to work - cifs_sign_smb2 (called from SendReceive2) is not complete but SendReceive2 is needed in ever more paths (including obviously now Read).
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: March 31, 2006
From: Steve French <smfltc@xxxxxxxxxx>
In-reply-to:
<442D3F11.1090905@xxxxxx>
References:
<442D3F11.1090905@xxxxxx>
Alan Tyson wrote:
What is the kernel version (and cifs version) of fc5 - did your original fc5 build have the checks in cifs_unlink forSteve,Thanks very much for the patch. There was a typo in it: "dentry" should have been "direntry". I've tested this using SLES9 and also FC5 as my base and the OOPS is fixed as far as I can tell. However, I'm now getting occasional client hangs when I run two occurrences of the test on the same client simultaneously. I'll need a few days to look at this in detail and will report back next week.Thank you, Alan.
if(direntry->d_inode != NULL)
The fix for cifs_unlink oops (which I would have expected to fix it -
went in the cifs tree 5/17/2005)
http://kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=b2aeb9d565be5ef00fb9f921c6d2459c74d90cdfThinking about this problem more - the above should have been what fixed it not what I changed (which although harmless is unlikely to matter)
Date: March 31, 2006
From: Alan Tyson <atyson@xxxxxx>
Steve,Thanks very much for the patch. There was a typo in it: "dentry" should have been "direntry". I've tested this using SLES9 and also FC5 as my base and the OOPS is fixed as far as I can tell. However, I'm now getting occasional client hangs when I run two occurrences of the test on the same client simultaneously. I'll need a few days to look at this in detail and will report back next week.
Thank you, Alan.
Date: March 31, 2006
From: Steve French <smfrench@xxxxxxxxxxxxx>
Let me know what you find - thanks:http://www.kernel.org/git/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=6910ab30a29d10e0fec7710b2ed857a2201e2468
Date: March 31, 2006
From: Alexander Bokovoy <ab@xxxxxxxxx>
In-reply-to:
<4417A123.8060308@xxxxxxxxxxxxx>
References:
<4417A123.8060308@xxxxxxxxxxxxx>
Steve French пишет:
I have created a converged cifs 1.42 source tarball (ie current cifs) which should build and work on (roughly) 2.6.8 or later kernels. This is only slightly beyond what was tested at Connectathon a few weeks ago. Obviously I don't have every possible kernel version between 2.6.8 and 2.6.16-rc5 to try this on but I have built and lightly tested on a few different kernel versions today (which went fine) to ensure that the new ifdefs do take care of the global kernel changes for each major kernel version. I ran out of time today to back port it all the way back to 2.6.5 (SLES9) but will try to finish that up later. There are a surprisingly number of little differences in the vfs between Linux kernel versions.
Following patch is required for SLES9. I finally managed to get 1.42a up and running on SLES9/x86 and SLES9/ia64 with it. One thing we might need to consider is some support to get user authorization within cifs for MultiuserMount case without actual additional mounts. I would suggest to add special option to mount options so that username and password passed with mount request (and this option) will cause smb logon but no actual mount operation when /proc/fs/cifs/MultiuserMount is 1. This smb session then will be cached up until umount call with the same path would be received. This would allow true multiuser mount with less clutter, we definitely don't need to mount dozen shares to get those user credentials within cifs sessions' cache. -- / Alexander Bokovoy Samba Team http://www.samba.org/ ALT Linux Team http://www.altlinux.org/ Midgard Project Ry http://www.midgard-project.org/
diff -urN cifs/cifsproto.h cifs.new/cifsproto.h
--- cifs/cifsproto.h 2006-03-19 16:16:56.000000000 -0800
+++ cifs.new/cifsproto.h 2006-03-29 04:53:27.636786512 -0800
@@ -29,6 +29,10 @@
#define kvec iovec
#endif
+#ifndef msleep
+#define msleep(x) { set_current_state(TASK_UNINTERRUPTIBLE);
schedule_timeout(x * HZ / 1000); }
+#endif
+
/*
*****************************************************************
* All Prototypes
diff -urN cifs/connect.c cifs.new/connect.c
--- cifs/connect.c 2006-03-19 16:52:56.000000000 -0800
+++ cifs.new/connect.c 2006-03-29 05:51:11.160250912 -0800
@@ -351,6 +351,9 @@
int isLargeBuf = FALSE;
int isMultiRsp;
int reconnect;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ mm_segment_t temp_fs;
+#endif
daemonize("cifsd");
allow_signal(SIGKILL);
@@ -368,6 +371,11 @@
GFP_KERNEL);
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ temp_fs = get_fs(); /* we must turn off socket api parm checking */
+ set_fs(get_ds());
+#endif
+
while (server->tcpStatus != CifsExiting) {
#if LINUX_VERSION_CODE > KERNEL_VERSION(2, 6, 10)
if (try_to_freeze())
@@ -678,6 +686,10 @@
sock_release(csocket);
server->ssocket = NULL;
}
+
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ set_fs(temp_fs);
+#endif
/* buffer usuallly freed in free_mid - need to free it here on exit */
if (bigbuf != NULL)
cifs_buf_release(bigbuf);
diff -urN cifs/transport.c cifs.new/transport.c
--- cifs/transport.c 2006-03-19 17:55:06.000000000 -0800
+++ cifs.new/transport.c 2006-03-29 06:04:50.899631584 -0800
@@ -150,6 +150,9 @@
struct msghdr smb_msg;
struct kvec iov;
unsigned len = smb_buf_length + 4;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ mm_segment_t temp_fs;
+#endif
if(ssocket == NULL)
return -ENOTSOCK; /* BB eventually add reconnect code here */
@@ -175,6 +178,10 @@
cFYI(1, ("Sending smb of length %d", smb_buf_length));
dump_smb(smb_buffer, len);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ temp_fs = get_fs(); /* we must turn off socket api parm checking */
+ set_fs(get_ds());
+#endif
while (len > 0) {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
rc = sock_sendmsg(ssocket, &smb_msg, len);
@@ -204,6 +211,9 @@
iov.iov_len -= rc;
len -= rc;
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ set_fs(temp_fs);
+#endif
if (rc < 0) {
cERROR(1,("Error %d sending data on socket to server", rc));
@@ -225,6 +235,9 @@
unsigned int len = iov[0].iov_len;
unsigned int total_len;
int first_vec = 0;
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ mm_segment_t temp_fs;
+#endif
if(ssocket == NULL)
return -ENOTSOCK; /* BB eventually add reconnect code here */
@@ -249,6 +262,10 @@
cFYI(1, ("Sending smb: total_len %d", total_len));
dump_smb(smb_buffer, len);
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ temp_fs = get_fs(); /* we must turn off socket api parm checking */
+ set_fs(get_ds());
+#endif
while (total_len) {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
smb_msg.msg_iov = &iov[first_vec];
@@ -301,6 +318,9 @@
}
i = 0; /* in case we get ENOSPC on the next send */
}
+#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 8)
+ set_fs(temp_fs);
+#endif
if (rc < 0) {
cERROR(1,("Error %d sending data on socket to server", rc));
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 30, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<442C2B91.9040407@xxxxxx>
References:
<442C2B91.9040407@xxxxxx>
In the case you describe (no inode data for the parent directory of the target file on rename) It makes more sense (and seems safer) to try to fix it lower down by instead getting the inode pointer from the dentry in cifs_unlink (and if there is some race in which we think it is a negative dentry - ie no dentry->inode then we can fail cifs_unlink).
I will put a patch out in the cifs-2.6 git tree later today.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Alan Tyson <atyson@xxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 03/30/2006 01:03 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 30, 2006
From: Alan Tyson <atyson@xxxxxx>
Hi,I have been working with one of our customers who is planning on using cifs clients in their network. As part of their stress testing, they have hit a problem in the cifs module when multiple clients are moving files from one directory on the server to another one. Both directories are under the same mount point and the problem (sometimes) happens when two clients try to perform the same move at the same time (not a particularly smart thing to do, but serves it's purpose here).
The symptoms of the problem are an OOPS caused by an attempt at a null pointer dereference followed by client hangs.
Our customer is using SLES9 SP3 which has the 1.33 version of the cifs client. I can also duplicate the problem using Fedora Core 5 which has the 1.40 version of the client and, whilst I've not specifically tested it, I feel that the problem is still there in the latest version.
I believe that I have identifed the root cause of the problem. I'm not too sure about the ettiqiette of what I should post here and what I should put into a bugzilla describing what I've found, so some guidance in this area would be appreciated.
For the curious, the oops is (trying to keep it brief): Unable to handle kernel NULL pointer dereference at virtual address 0000002c crash> bt PID: 15948 TASK: dee72000 CPU: 1 COMMAND: "mv" #0 [d92d7cb0] schedule at c012642a #1 [d92d7d38] SendReceive at e0d4ab8c #2 [d92d7da8] error_code at c010a27bEAX: 00000000 EBX: d9ec13c0 ECX: df6da638 EDX: d97f0b80 EBP: 0002073a
DS: 007b ESI: d9265968 ES: 007b EDI: 00000000 CS: 0060 EIP: e0d3a7c3 ERR: ffffffff EFLAGS: 00010246 #3 [d92d7de4] cifs_unlink at e0d3a7c3 #4 [d92d7e44] cifs_rename at e0d3acf7 #5 [d92d7ea0] vfs_rename_other at c0183821 #6 [d92d7ec0] vfs_rename at c0184ca2 #7 [d92d7edc] sys_rename at c0186e91 #8 [d92d7fc0] sysenter_entry at c01091d2and I believe that the fix would be to make the call to cifs_unlink from cifs_rename conditional upon dentry->d_inode being not NULL, but can post more information here or in a bugzilla, as you suggest.
Many thanks, Alan Tyson, Global Solutions Engineering, Hewlett Packard.
Date: March 29, 2006
From: Tomasz Chmielewski <mangoo@xxxxxxxx>
In-reply-to:
<OFE4BA90F7.FA2DB482-ON8725713F.00595DB2-8625713F.00599D80@xxxxxxxxxx>
References:
<OFE4BA90F7.FA2DB482-ON8725713F.00595DB2-8625713F.00599D80@xxxxxxxxxx>
Steven French wrote:
I see one reference to ReiserFS allowing longer than 255 bytes per path name component (perhaps 255 UTF-8 character max) but I have not verified it.
I just tried with reiser3 - it's the same maximum length as with ext3. -- Tomasz Chmielewski http://wpkg.org
Date: March 28, 2006
From: studdugie <studdugie@xxxxxxxxx>
I have 2 kernel versions built from kernel.org's tree. Versions 2.6.15.1 and 2.6.11.5 and 2.6.15.1's CIFS client is not working as expected. I have a bash script that mounts a Windows 2003 share, moves 1 directory down from the mount point, and for each sub-directory in the 1-down directory it empties the sub-directories' contents via rm. It then grabs the latest version of the files that it just deleted from Subversion and tries to repopulate the sub-directories it just emptied via cp. It partially fails and the way it fails is funky. Everything, including rm, works fine but cp gets weird. The source directory looks something like this: export-dir/src/ .... bunch of files .... bunch of directories The command issued to copy the files is: cp -R export-dir/src/* [for each] /mnt/win-share/dev/[sub-dir] cp manages to copy "bunch of files" no problem. But when it gets to "bunch of directories" one of (or all) 3 things happen: 1) cp reports "cannot create directory .... Permission denied" 2) cp creates the directory but then reports "setting permissions for [directory name]: Operation not permitted" 3) cp can't popluate the directory it just created. It reports "cannot create regular file [filename]: Permission denied" When I switch back to the 2.6.11.5 kernel everything works perfectly so I can only conclude that there is something wrong with 2.6.15.1's CIFS client. I know this post is short technical details but I'm willing to perform any necessary action to produce the type of data that may help is fixing this problem. Regards, Dane
Date: March 28, 2006
From: "Naidu Bollineni" <naidu@xxxxxxxxxx>
|
We have had an issue with character set
recently with 2.4. It turned out that the 2.4 kernel is setting the
CONFIG_NLS_DEFAULT to iso8859-1, so applications had difficulty handling the
different language characters. When we changed it to “utf8” it
made everything smooth. I have in fact tried the cifs module on 2.6.15-3
without any changes and that seems to be fine because 2.6 is setting utf8 as
default. Its actually very easy to create files
with such characters on windows. (I have XP pro). Goto Start àAll Programs àAccessoriesàSystem ToolsàCharacter Map. And here
you can select the characters, copy/paste into file names on explorer on a
rename of a new file being created. From:
linux-cifs-client-bounces+naidu=kazeon.com@xxxxxxxxxxxxxxx
[mailto:linux-cifs-client-bounces+naidu=kazeon.com@xxxxxxxxxxxxxxx] On Behalf Of Steven French I see one reference to ReiserFS allowing longer than
255 bytes per path name component (perhaps 255 UTF-8 character max) but I have
not verified it. Presumably NTFS limit is 255 wchars (UCS-16) or 510 bytes -
and when converted to UTF-8 exceeds 255 bytes? I would love to have a sample
set of empty UTF-8 files - perhaps a tar.gz file which contains files whose
names are composed of various UTF-8 characters which are longer than 2 bytes
each - or alternatively a good NLS testcase for this kind of thing.
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 28, 2006
From: Tomasz Chmielewski <mangoo@xxxxxxxx>
In-reply-to:
<OFE4BA90F7.FA2DB482-ON8725713F.00595DB2-8625713F.00599D80@xxxxxxxxxx>
References:
<OFE4BA90F7.FA2DB482-ON8725713F.00595DB2-8625713F.00599D80@xxxxxxxxxx>
Steven French wrote:
I see one reference to ReiserFS allowing longer than 255 bytes per path name component (perhaps 255 UTF-8 character max) but I have not verified it. Presumably NTFS limit is 255 wchars (UCS-16) or 510 bytes - and when converted to UTF-8 exceeds 255 bytes? I would love to have a sample set of empty UTF-8 files - perhaps a tar.gz file which contains files whose names are composed of various UTF-8 characters which are longer than 2 bytes each - or alternatively a good NLS testcase for this kind of thing.
I can send you such a file (in the morning). Could you please post your messages as text, and not HTML? It seems that HTML messages don't show up in the list archive. -- Tomasz Chmielewski
Date: March 28, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20060328091705.GA10502@xxxxxxxxxxxxxxxxxxx>
References:
<20060328091705.GA10502@xxxxxxxxxxxxxxxxxxx>
I see one reference to ReiserFS allowing longer than 255 bytes per path name component (perhaps 255 UTF-8 character max) but I have not verified it. Presumably NTFS limit is 255 wchars (UCS-16) or 510 bytes - and when converted to UTF-8 exceeds 255 bytes? I would love to have a sample set of empty UTF-8 files - perhaps a tar.gz file which contains files whose names are composed of various UTF-8 characters which are longer than 2 bytes each - or alternatively a good NLS testcase for this kind of thing.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Sergey Vlasov <vsu@xxxxxxxxxxx>
03/28/2006 03:17 AM |
|
att8n8ki.dat
Description: Binary data
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 28, 2006
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
In-reply-to:
<20060328091705.GA10502@xxxxxxxxxxxxxxxxxxx>
References:
<OF54C04C7B.7EDE02BD-ON8725713E.005F68AB-8625713E.005F6ACB@xxxxxxxxxx> <4428F652.8060305@xxxxxxxx> <20060328091705.GA10502@xxxxxxxxxxxxxxxxxxx>
On Tue, 2006-03-28 at 13:17 +0400, Sergey Vlasov wrote: > Actually the file name limit for ext2/3 and xfs is 255 _bytes_, but each > non-ASCII character occupies at least two bytes in UTF-8 (CJK and some > special characters need 3 bytes). > > Not sure about jfs (seems to be 255 bytes too, but jfs stores file names > in Unicode internally, and this might introduce some complications). By default, jfs doesn't convert to Unicode anymore, but stores the bytes as they are. You would need to mount with -o iocharset=utf8 to get jfs to convert the file names to Unicode (UCS-16, or whatever it's called). I'm pretty sure jfs still rejects names that are greater then 255 characters long, unconverted. -- David Kleikamp IBM Linux Technology Center
Date: March 28, 2006
From: Hadmut Danisch <hadmut@xxxxxxxxxx>
Hi, is there any documentation about how to use cifs with kerberos in recent kernels? E.g. when I query our local server with smbclient -k -L dc1 it works and makes use of Kerberos, but then when I try mount -o sec=krb5,user=danisch -t cifs //dc1/files /X it still asks me for the password. What am I doing wrong? regards Hadmut
Date: March 28, 2006
From: Sergey Vlasov <vsu@xxxxxxxxxxx>
In-reply-to:
<4428F652.8060305@xxxxxxxx>
References:
<OF54C04C7B.7EDE02BD-ON8725713E.005F68AB-8625713E.005F6ACB@xxxxxxxxxx> <4428F652.8060305@xxxxxxxx>
On Tue, Mar 28, 2006 at 10:39:46AM +0200, Tomasz Chmielewski wrote: > Steven French wrote: > >Could you verify that the directory can be created locally on Linux (in > >e.g. ext3 or jfs or xfs) and do you have an estimate of the path > >component length (for the particular directory name) and the total > >filename length in bytes (UTF-8 encoded)? > > Indeed, it's not possible (I tried with ext3 and tmpfs) to create a file > that long on a Linux side. > > So it looks like Windows can have filenames longer than Linux do? How do > we copy long files from Windows then? > > It looks like it's impossible, on the Linux side, to create a file or > directory name that is longer than 127 characters (all characters UTF-8). Actually the file name limit for ext2/3 and xfs is 255 _bytes_, but each non-ASCII character occupies at least two bytes in UTF-8 (CJK and some special characters need 3 bytes). Not sure about jfs (seems to be 255 bytes too, but jfs stores file names in Unicode internally, and this might introduce some complications).
pgpAy6A1Z7HjC.pgp
Description: PGP signature
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 28, 2006
From: Tomasz Chmielewski <mangoo@xxxxxxxx>
In-reply-to:
<OF54C04C7B.7EDE02BD-ON8725713E.005F68AB-8625713E.005F6ACB@xxxxxxxxxx>
References:
<OF54C04C7B.7EDE02BD-ON8725713E.005F68AB-8625713E.005F6ACB@xxxxxxxxxx>
Steven French wrote:
Could you verify that the directory can be created locally on Linux (in e.g. ext3 or jfs or xfs) and do you have an estimate of the path component length (for the particular directory name) and the total filename length in bytes (UTF-8 encoded)?
Indeed, it's not possible (I tried with ext3 and tmpfs) to create a file that long on a Linux side.
So it looks like Windows can have filenames longer than Linux do? How do we copy long files from Windows then?
It looks like it's impossible, on the Linux side, to create a file or directory name that is longer than 127 characters (all characters UTF-8).
-- Tomasz Chmielewski http://wpkg.org
Date: March 27, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<4427D0B6.8010704@xxxxxxxx>
References:
<4427D0B6.8010704@xxxxxxxx>
Could you verify that the directory can be created locally on Linux (in e.g. ext3 or jfs or xfs) and do you have an estimate of the path component length (for the particular directory name) and the total filename length in bytes (UTF-8 encoded)?
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Tomasz Chmielewski <mangoo@xxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 03/27/2006 05:47 AM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 27, 2006
From: Tomasz Chmielewski <mangoo@xxxxxxxx>
I have a Windows 2003 server, from which I wanted to backup user profiles. I mount the share on a Linux server running 2.6.12 kernel like this:mount.cifs //server/share /mnt/server -o ro,username=admin,password=pass,iocharset=utf8
On that share, I have some long directories, which contain about 150 Cyrillic characters.
It's impossible to copy them, "cp" or "rsync" throw "File name too long" error.
Is there a solution for this? -- Tomasz Chmielewski http://wpkg.org
Date: March 24, 2006
From: Christian Hartmann <cornbob@xxxxxx>
Sergey
Vlasov <vsu@xxxxxxxxxxx>
Hello list,
I have searched this list, the kernel mailinglist and many other boards and
forums for about 3 month now and I have not found an answer for the following
problem:
We have samba servers with kernel 2.6.15 running and some (more than two)
clients, which ran into problems.
This clients are using cifs-shares from a Samba Server with version
cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
---------------------------------------------------
CIFS Version 1.39
Active VFS Requests: 0
Servers:
1) Name: 192.168.x.x Domain: EEIS Mounts: 1 OS: Unix
NOS: Samba 3.0.9-2.6-SUSE Capability: 0x80e3fd
An error occurred and this is also reproducible, which freezes the linux kernel
- only ping to this samba-cifs-client is working, the machine is up and running,
but it has no more available system resources (they are gone by cifs-vfs)
they have no more available file-descriptions,
so all process are hanging, waiting (system wait is about 80 till 99%) for
free'd FDs.
But it MUST be a infinite loop in the cifs-client code.
I have to hard reboot the hosts, cause all services like ssh are not responding
anymore.
To find the faulty part I have changed the kernel,compiled a new kernel
(2.6.15.4) changing the debug options for kernel AND/OR for cifs.
Setting file-max to an higher value, testing with smbfs (not working for us)
Trying also cifs Version 1.40 and so on...
The system freeze happened randomized everytime (about between one day and a
week)
I discovered some things:
1) If host (a) does a /usr/bin/convert over cifs to the server and the other
host (b) reads/writes in the same time to the same file on the server - crash
2) if I enable cifsFYI (echo 1 > /proc/fs/cifs/cifsFYI) the clients are NOT
crashing anymore (uptime now over 18days !!!) disable it will and up in a crash
SOON.
3) in some freezes I find the following messages (/var/log/messages)
VFS: file-max reached !
Hint: I strac'd, gdb'd and valgrind'd the php-applications (which are doing a
lot of fileoperation over CIFS)
and the only thing I could find/see was the collisions of to simultanous access
to the same file over the cifs-server - one of the cifs-clients ends up in a
freeze (must reboot the host )
In two of these cases I could see rising the file-max value, which in normal has
about 2200 till 3500 used filedescriptores, in 1 or 2 seconds from the normal
(ca 3000) to up to 102786 !!!!
I could not kill nor delete as fast as it was wasting all fds.
4) If I do an /bin/du -h /path/to/cifs/share
I got sooner or later no response anymore; the kernel log on the samba server
shows:
<snip>
fs/cifs/connect.c: rfc1002 length 0x85000004)
fs/cifs/connect.c: rfc1002 length 0x85000004)
fs/cifs/connect.c: rfc1002 length 0x85000004)
fs/cifs/connect.c: rfc1002 length 0x85000004)
....
</snipped>
So I am currently running the hosts with cifsFYI enabled and I have no crashes
yet.
Any help would be appreciate.
Sincerely and thx-in-advance
Chris
--
"With sufficient thrust, pigs fly just fine." -- RFC 1925
:wq!
Date: March 22, 2006
From: "Peter Diekert" <diekert@xxxxxxxxxxx>
|
I mounted a directory an a Windows-2000-Prof. System with
cifs. I see that directory and I can edit files and start programs. But: I like
to use sqlite. When I start sqlite on the router, it works perfectly. Peter Diekert
DataChem GmbH Siedlergrund 12a D-09212 Limbach-Oberfrohna Tel.: +49 (3722) 817357 Fax.: +49 (3722) 817358 Internet: www.datachem.de eMail: diekert@xxxxxxxxxxx |
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 21, 2006
From: Adrian Bunk <bunk@xxxxxxxxx>
Hi Steve,
I discovered two other problems with CIFS:
I'm connecting to a Samba server.
This is with the same computers as my now fixed hangs, but this time I
am trying to copy data to the server.
All the below was observed on an otherwise mostly idle machine.
With 2.6.16, the data transfer make the whole computer very sluggish,
this seems to be fixed in 2.6.16-rc6-mm2. But the following issues
remain:
When copying with "cp" or "mc" to the share and suspending the program
copying with ^Z, the data transfer seems to continue.
When running "sync" from another shell during a data transfer, the sync
hangs. After killing cifsd, "sync" returns immediately.
CIFS options in my kernel:
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
I'm mounting with (slightly anonymized):
mount -t cifs -o user="foo",ip=11.22.33.44 //DAT/bar bar
I'm using the smbfs 3.0.21b-1 package from Debian.
I'm using an e100 network card with a 10 MBit/s connection.
Any other information I can provide for helping to debug this problem?
TIA
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Date: March 15, 2006
From: Steve French <smfrench@xxxxxxxxxxxxx>
On the website I would like to keep just two versions of cifs code going forward (instead of various distinct ones for various old kernels) a) cifs-2.6.git (the current development branch) which gets pulled automatically into -mm (no ifdefs for kernel versions per typical kernel style) b) the version with the various ifdefs to allow it to build on lots of different kernel versions from 2.6.5 through 2.6.15, or whatever the previous kernel version is
Obviously this is in addition to the the mainline 2.6 linux kernel itself (which gets updated somewhat less frequently from the cifs devel branch. I will try to keep these synced reasonably up to date in Samba svn (linux-cifs-client project) as well but git will be the main repository. To build this:
1) download http://pserver.samba.org/samba/ftp/cifs-cvs/cifs-1.42.tar.gz 2) untar it (e.g. gunzip cifs-1.42.tar.gz then tar -xvf cifs-1.42.tar)3) cd to the root of your kernel's build directory (e.g. /usr/src/<kernel-ver>
4) make M=~/cifs-1.42-scratch/fs/cifs 5) /sbin/insmod ~/cifs-1.42-scratch/fs/cifs/cifs.ko6) if you test it and like this version, back up your /lib/modules/<kernel-version>/kernel/fs/cifs/cifs.ko file and replace it with the newly built one
If this works or doesn't work let me know.
Date: March 12, 2006
From: "Howard W" <howard007@xxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 10, 2006
From: Andrew Bartlett <abartlet@xxxxxxxxx>
In-reply-to:
<44112DEC.2080205@xxxxxxxxxxxx>
References:
<44109A5F.805@xxxxxxxxxxxx> <1141972471.9991.259.camel@xxxxxxxxxxxxxxxxxxxxx> <44112DEC.2080205@xxxxxxxxxxxx>
On Fri, 2006-03-10 at 01:42 -0600, Christopher R. Hertel wrote: > Andrew Bartlett wrote: > : > >>The problem seems to be the case of the principal. The Celerra goes > >>against the grain by sending principal names in the form NAME@realm (that > >>is, UPPER@lower). The Windows KDC will "canonicalize" the name changing it > >>to name@REALM (that is, lower@UPPER). > > > > A well known behaviour. > > Which, the behavior of the Windows KDC or the odd choice of capitalization > from the server? The windows KDC behaviour. > > I'll assert that it would be far, far easier for one commercial NAS > > device to check AD for the correct case than for all the Linux and Apple > > MAC clients in the world to change behaviour. > > My feelings as well, but I need to convince the vendor that it is worth > doing. They live in a windows only world I presume? :-) We can't fix what clients are out there. I would have thought that this is an easy fix, compared to the customer pain, but clearly they don't feel that... Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 10, 2006
From: "Christopher R. Hertel" <crh@xxxxxxxxxxxx>
In-reply-to:
<1141972471.9991.259.camel@xxxxxxxxxxxxxxxxxxxxx>
References:
<44109A5F.805@xxxxxxxxxxxx> <1141972471.9991.259.camel@xxxxxxxxxxxxxxxxxxxxx>
Andrew Bartlett wrote: :
The problem seems to be the case of the principal. The Celerra goes against the grain by sending principal names in the form NAME@realm (that is, UPPER@lower). The Windows KDC will "canonicalize" the name changing it to name@REALM (that is, lower@UPPER).A well known behaviour.
Which, the behavior of the Windows KDC or the odd choice of capitalization from the server?
I'll assert that it would be far, far easier for one commercial NAS device to check AD for the correct case than for all the Linux and AppleMAC clients in the world to change behaviour.
My feelings as well, but I need to convince the vendor that it is worth doing. Thanks ever so much! Chris -)----- -- "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: March 10, 2006
From: Andrew Bartlett <abartlet@xxxxxxxxx>
In-reply-to:
<44109A5F.805@xxxxxxxxxxxx>
References:
<44109A5F.805@xxxxxxxxxxxx>
On Thu, 2006-03-09 at 15:13 -0600, Christopher R. Hertel wrote: > Here's an interesting buglet I ran into recently... > > (Andrew Bartlett, it's been suggested that I solicit your opinion here...) > > I've got commercial NAS device, acting as a CIFS server. It's a member > of an AD domain that only accepts Kerberos Auth. Windows clients are able > to authenticate and gain access to the CIFS shares without problems. > > Other clients--MacOS's SMB file system, the Linux CIFS VFS, and smbclient-- > all fail with an error along the lines of: > > spnego_gen_negTokenTarg failed: KDC reply did not match expectations > > The problem seems to be the case of the principal. The Celerra goes > against the grain by sending principal names in the form NAME@realm (that > is, UPPER@lower). The Windows KDC will "canonicalize" the name changing it > to name@REALM (that is, lower@UPPER). A well known behaviour. > As described above, the Windows clients appear not to care about the case > of the fields of the principal, but the MacOS and Linux clients do. Yep. It isn't perhaps the best idea (there are some vague security reasons not to), but it does make things work a lot more often. > I have highly-respected contacts within the company that makes the NAS > device. They assure me that the problem is that the clients are being > too picky, and that case should not matter. I am also fairly certain, > however, that this authentication would work if the CIFS server were > providing its principal name in the preferred lower@UPPER format (so > that it would be the same as the format the Windows KDC returns). Yes, the client is being picky, but the server is being painful. > I'm looking for comments regarding this. I'd like to know, in particular, > whether or not folks think changes need to be made in the above-mentioned > clients. In Samba4, I don't rely on the principal name from the negtokeninit. This better matches windows behaviour. However, I still supply the principal name, because I think that a product in the marketplace should not make itself any less compatible than possible. I'll assert that it would be far, far easier for one commercial NAS device to check AD for the correct case than for all the Linux and Apple MAC clients in the world to change behaviour. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Student Network Administrator, Hawker College http://hawkerc.net
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: March 10, 2006
From: "Danilo Almeida" <dalmeida@xxxxxxxxxxxx>
I am looking for a good explanation of the differences between the cifs
and smbfs filesystems. The only documentation that I have found so far
is /usr/src/linux/Documentation/filesystems/{cifs,smbfs} and
/usr/src/linux/fs/cifs/README. I have also extracted information from
mailing list archives.
As far as I can tell, the biggest different is that cifs is newer and
has been support for the newer CIFS dialects.
I am trying to figure out how (and whether) it is possible to configure
cifs or smbfs to allow access to UNC paths by multiple users. I have
not yet been able to mount w/o specifying specific credentials to use
for the mount.
>From what I have been able to gather, it looks like cifs wants to go in
the direction of using Linux keyrings (though I am not sure how far that
work has gone) to do per-user credentials.
Any information on making this work (now or in the future) would be
appreciated.
Thanks,
- Danilo
Date: March 09, 2006
From: "Christopher R. Hertel" <crh@xxxxxxxxxxxx>
Here's an interesting buglet I ran into recently... (Andrew Bartlett, it's been suggested that I solicit your opinion here...) I've got commercial NAS device, acting as a CIFS server. It's a member of an AD domain that only accepts Kerberos Auth. Windows clients are able to authenticate and gain access to the CIFS shares without problems. Other clients--MacOS's SMB file system, the Linux CIFS VFS, and smbclient-- all fail with an error along the lines of: spnego_gen_negTokenTarg failed: KDC reply did not match expectations The problem seems to be the case of the principal. The Celerra goes against the grain by sending principal names in the form NAME@realm (that is, UPPER@lower). The Windows KDC will "canonicalize" the name changing it to name@REALM (that is, lower@UPPER). As described above, the Windows clients appear not to care about the case of the fields of the principal, but the MacOS and Linux clients do. I have highly-respected contacts within the company that makes the NAS device. They assure me that the problem is that the clients are being too picky, and that case should not matter. I am also fairly certain, however, that this authentication would work if the CIFS server were providing its principal name in the preferred lower@UPPER format (so that it would be the same as the format the Windows KDC returns). I'm looking for comments regarding this. I'd like to know, in particular, whether or not folks think changes need to be made in the above-mentioned clients. Thanks. Chris -)----- -- "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: March 09, 2006
From: Daniel K <dkar@xxxxxx>
In-reply-to:
<440C8C8B.8020407@xxxxxxxxxx>
References:
<440C8C8B.8020407@xxxxxxxxxx>
Hi,
I just did some testing. I have a system running Kanotix with kernel 2.6.14. It obviously is too old and shows even more problems. The other system, on which I first came across these problems is a linux test system which works as a digital video recorder. Now, with recordings distributed across the network is can get very annoying if e.g. the on-screen display freezes if another system is down. Anyway, this system is running 2.6.16-rc5 and uses an older version of busybox. That might be the reason because umount didn't work. I compiled your umount.cifs.c and it works just fine! Then I tried a newer busybox version and it too seemed to work. So, don't worry. There are no umount related problems. Only the long timeouts are a bit annoying.So I would like to know if you have an umount scenario on reasonably current code in which cifs won't umount (within 15 seconds) and should.
Bye and thanks for looking into this subject, Daniel
Date: March 08, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<440EB539.7020203@xxxxxxxx>
References:
<440EB539.7020203@xxxxxxxx>
There is no code in cifs (or any Linux kernel filesystem as far as I know) to map "rich ACLs" (such as Windows/CIFS ACLs or NFS version 4 ACL) to mode bits (Unix permissions) yet. That (mapping CIFS ACLs to and from mode bits) is something that has been started in the current CIFS code but not completed (anyone who wants to help with that would be welcome ... it is an interesting problem with some precedent in Samba code and also in a draft RFC that Bruce Fields of the NFSv4 community has been working).
With mount option "sfu" the cifs client will map the obscure Linux mode bits above 0777 to extended attributes but the bits 0777 and below still are taken from the default mode specified at mount ("dir_mode" and "file_mode") at least until the ACL mapping code is complete.
Mounts to servers supporting the Unix extensions (such as Samba) do not have this problem as the protocol supports reporting the mode bits and actual uid/gid of the owner.