Custom Search
|
Date: February 26, 2006
From: Daniel K <dkar@xxxxxx>
In-reply-to:
<5a59ce530602260948i2111abc7l6d06f17d88c8ac7f@xxxxxxxxxxxxxx>
References:
<4401CA15.7040304@xxxxxx> <5a59ce530602260948i2111abc7l6d06f17d88c8ac7f@xxxxxxxxxxxxxx>
Hi,
I once tried to reduce the hard coded time out values via a patch:
***begin***
--- a/fs/cifs/connect.c 2006-02-15 18:31:49.000000000 +0100
+++ b/fs/cifs/connect.c 2006-02-15 18:29:09.000000000 +0100
@@ -1433,7 +1433,7 @@
user space buffer */
cFYI(1,("sndbuf %d rcvbuf %d rcvtimeo
0x%lx",(*csocket)->sk->sk_sndbuf,
(*csocket)->sk->sk_rcvbuf, (*csocket)->sk->sk_rcvtimeo));
- (*csocket)->sk->sk_rcvtimeo = 7 * HZ;
+ (*csocket)->sk->sk_rcvtimeo = 2 * HZ;
/* make the bufsizes depend on wsize/rsize and max requests */
if((*csocket)->sk->sk_sndbuf < (200 * 1024))
(*csocket)->sk->sk_sndbuf = 200 * 1024;
@@ -1552,7 +1552,7 @@
/* Eventually check for other socket options to change from
the default. sock_setsockopt not used because it expects
user space buffer */
- (*csocket)->sk->sk_rcvtimeo = 7 * HZ;
+ (*csocket)->sk->sk_rcvtimeo = 2 * HZ;
return rc;
}
--- a/fs/cifs/transport.c 2006-02-15 18:31:49.000000000 +0100
+++ b/fs/cifs/transport.c 2006-02-15 18:29:09.000000000 +0100
@@ -426,7 +426,7 @@
else if (long_op > 2) {
timeout = MAX_SCHEDULE_TIMEOUT;
} else
- timeout = 15 * HZ;
+ timeout = 3 * HZ;
/* wait for 15 seconds or until woken up due to response arriving or
due to last connection to this server being unmounted */
if (signal_pending(current)) {
@@ -437,12 +437,10 @@
/* No user interrupts in wait - wreaks havoc with performance */
if(timeout != MAX_SCHEDULE_TIMEOUT) {
- timeout += jiffies;
- wait_event(ses->server->response_q,
- (!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
- time_after(jiffies, timeout) ||
+ wait_event_interruptible_timeout(ses->server->response_q,
+ (!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
((ses->server->tcpStatus != CifsGood) &&
- (ses->server->tcpStatus != CifsNew)));
+ (ses->server->tcpStatus != CifsNew)), timeout);
} else {
wait_event(ses->server->response_q,
(!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
@@ -693,7 +691,7 @@
else if (long_op > 2) {
timeout = MAX_SCHEDULE_TIMEOUT;
} else
- timeout = 15 * HZ;
+ timeout = 3 * HZ;
/* wait for 15 seconds or until woken up due to response arriving or
due to last connection to this server being unmounted */
if (signal_pending(current)) {
@@ -704,12 +702,10 @@
/* No user interrupts in wait - wreaks havoc with performance */
if(timeout != MAX_SCHEDULE_TIMEOUT) {
- timeout += jiffies;
- wait_event(ses->server->response_q,
- (!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
- time_after(jiffies, timeout) ||
+ wait_event_interruptible_timeout(ses->server->response_q,
+ (!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
((ses->server->tcpStatus != CifsGood) &&
- (ses->server->tcpStatus != CifsNew)));
+ (ses->server->tcpStatus != CifsNew)), timeout);
} else {
wait_event(ses->server->response_q,
(!(midQ->midState & MID_REQUEST_SUBMITTED)) ||
--- a/fs/cifs/cifssmb.c 2006-02-15 21:44:14.000000000 +0100
+++ b/fs/cifs/cifssmb.c 2006-02-15 18:29:09.000000000 +0100
@@ -111,7 +111,7 @@
timeout which is 7 seconds */
while(tcon->ses->server->tcpStatus == CifsNeedReconnect) {
wait_event_interruptible_timeout(tcon->ses->server->response_q,
- (tcon->ses->server->tcpStatus == CifsGood), 10 * HZ);
+ (tcon->ses->server->tcpStatus == CifsGood), 3 * HZ);
if(tcon->ses->server->tcpStatus == CifsNeedReconnect) {
/* on "soft" mounts we wait once */
if((tcon->retry == FALSE) ||
@@ -221,7 +221,7 @@
timeout which is 7 seconds */
while(tcon->ses->server->tcpStatus == CifsNeedReconnect) {
wait_event_interruptible_timeout(tcon->ses->server->response_q,
- (tcon->ses->server->tcpStatus == CifsGood), 10 * HZ);
+ (tcon->ses->server->tcpStatus == CifsGood), 3 * HZ);
if(tcon->ses->server->tcpStatus ==
CifsNeedReconnect) {
/* on "soft" mounts we wait once */
***end***
But I'm not an expert either, so anyone who has a better understanding
of what he's doing maybe could post some ideas. Another approach:
Perhaps it is possible to check whether the server is online by simply
pinging it prior to any access. I mean, in a LAN servers normally
respond within just a few milliseconds, so even an extremely short time
out would do the trick and save a lot of trouble.
I am sure, with the feature added to an upcoming version of CIFS, it
would get a far superior advantage over NFS and SMB.
Best regards, Daniel
Date: February 26, 2006
From: studdugie <studdugie@xxxxxxxxx>
In-reply-to:
<4401CA15.7040304@xxxxxx>
References:
<4401CA15.7040304@xxxxxx>
I wholeheartedly agree! CIFS inability to gracefully handle network failure is rediculous! As Daniel suggests, at a minium, one should be able to unmount a failed share. I'm forced to periodically restart, an otherwise stable Linux box, just because of this issue. I've complained about it before but I think it has fallen on deaf ears. If I had the resources to fix it myself I would but I don't so I can't. Dane On 2/26/06, Daniel K <dkar@xxxxxx> wrote: > Hi, > > ever since I began sharing files between Linux and Windows systems I've > been suffering from one major problem that affects smb, nfs as well as > cifs: Long lock ups on server down times. > > If the serving computer shuts down / crashes, every process hangs when > trying to access the still mounted share. Just try df, mount or ls. You > can't even umount the share in this condition! When using smb this was > very severe as you couldn't mount a share with a "soft" option. So the > process in fact just hung until I pressed reset. Now, with cifs it is > much better. But still the timeout is very long. And you still cannot > umount an offline share to prevent further lock ups. > > Now my suggestion would be to make the timeout adjustable (now it is > something like 30 seconds on every access). And maybe automatic umounts > if a share isn't available anymore. At least one should be able to > umount such a share. > > Best regards, > Daniel > _______________________________________________ > linux-cifs-client mailing list > linux-cifs-client@xxxxxxxxxxxxxxx > https://lists.samba.org/mailman/listinfo/linux-cifs-client >
Date: February 26, 2006
From: Daniel K <dkar@xxxxxx>
Hi,ever since I began sharing files between Linux and Windows systems I've been suffering from one major problem that affects smb, nfs as well as cifs: Long lock ups on server down times.
If the serving computer shuts down / crashes, every process hangs when trying to access the still mounted share. Just try df, mount or ls. You can't even umount the share in this condition! When using smb this was very severe as you couldn't mount a share with a "soft" option. So the process in fact just hung until I pressed reset. Now, with cifs it is much better. But still the timeout is very long. And you still cannot umount an offline share to prevent further lock ups.
Now my suggestion would be to make the timeout adjustable (now it is something like 30 seconds on every access). And maybe automatic umounts if a share isn't available anymore. At least one should be able to umount such a share.
Best regards, Daniel
Date: February 20, 2006
From: JG <jg@xxxxxx>
In-reply-to:
<OF4CEF7B2E.D222EEA8-ON8725711B.00698C52-8625711B.00699ADC@xxxxxxxxxx>
References:
<20060220194748.28fd2783@xxxxxxxxxxxxxx> <OF4CEF7B2E.D222EEA8-ON8725711B.00698C52-8625711B.00699ADC@xxxxxxxxxx>
hi, > share level security support for cifs (for security reasons ntlm only > not lanman, but that works for Samba) was > added in the midst of cifs 1.40 which is in mainline linux kernel now. i was confused because "man smb.conf" states that the "admin user" option shouldn't work at all but it did. i've updated my kernel and used this CIFS version (and applied the first patch, the other one was already in the package): http://archives.free.net.ph/message/20060130.031308.28d3e105.en.html i dunno if you got an answer back in january, but it works (applies and so far no other problems) with kernel 2.6.15.4! i've changed the samba settings back to "security = share" and mounting with cifs works! thanks very much! JG
Date: February 20, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20060220194748.28fd2783@xxxxxxxxxxxxxx>
References:
<20060220194748.28fd2783@xxxxxxxxxxxxxx>
> well, this parameter worked with smbfs with security = share,
> but not with cifs!
share level security support for cifs (for security reasons ntlm only not lanman, but that works for Samba) was
added in the midst of cifs 1.40 which is in mainline linux kernel now.
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: February 20, 2006
From: JG <jg@xxxxxx>
hi,
i've always been using mount -t smbfs and recently "upgraded" to
mount.cifs because i have a very aggressive application which always
killed the smb connection (getting timeouts, ...).
my setup:
* some passwordless public/guest shares
* one admin share over a x-over link
to be able to use the admin share i had to switch my server from
"security = share" to "security = user", otherwise i always got
mount.cifs error -1, Operation not permitted.
now that was weird, because it always worked with smbfs, although the
man page states:
parameter: admin user = jg
"This parameter will not work with the security = share in Samba 3.0.
This is by design."
=> well, this parameter worked with smbfs with security = share, but not
with cifs!
now with "security = user" i can mount this admin share, but all the
public/guest shares are not mountable with CIFS, only with SMBFS.
here's a sample share:
[disk1]
path = /mnt/disk1
valid users = nobody ftp *guest
read only = Yes
guest ok = Yes
guest only = Yes
hide unreadable = Yes
hide special files = Yes
invalid users = root admin @wheel
veto files = /*root*/
browsable = Yes
i tried to mount the public share with many different settings regarding
user=, guest, sec=none, but i only get:
CIFS VFS: Send error in SessSetup = -13
CIFS VFS: cifs_mount failed w/return code = -13
i also tried to disable "PacketSigningEnabled", nothing helps. with
sec=none, dmesg tells me that it is an unknown mount option?
is there no way to perform a null session?
i have configured the smb.conf global settings like this:
encrypt passwords = yes
passdb backend = smbpasswd:/etc/samba/private/smbpasswd
username map = /etc/samba/smbusers
unix extensions = yes
the smbpasswd contains a nobody user with no password and my admin user.
cat /etc/samba/smbusers:
root = administrator admin root
nobody = guest pcguest smbguest
both client and server are samba v3.0.21b. kernel version is 2.6.15.1
on both sides. for the windows clients i'm using the workaround 'net
use \\IP\share "" "/USER:"' to be able to access the shares.
thanks for any enlightenment :)
JG
Date: February 16, 2006
From: Adrian Bunk <bunk@xxxxxxxxx>
In-reply-to:
<OFD6EC212C.9D3CD1CC-ON87257115.0057751D-86257115.0057E155@xxxxxxxxxx>
References:
<20060214135016.GC10701@xxxxxxxxx> <OFD6EC212C.9D3CD1CC-ON87257115.0057751D-86257115.0057E155@xxxxxxxxxx>
On Tue, Feb 14, 2006 at 10:01:59AM -0600, Steven French wrote:
>
> >...
> > It doesn't occur in 2.6.15.4, because with this kernel (and AFAIR also
> > with older kernels) my computer refuses to mount this share.
> >...
Is this issue I mentioned in my bug report expected, or could it be
related to my problem?
>...
> Command 46 is an SMB Read. IIRC send error in read -11 is EAGAIN which
> could
> indicate that the socket is congested and stayed congested but normally
> that would be accompanied by a "sends on socket stuck for x seconds"
>
> Could you check /proc/fs/cifs/DebugData and see if the number of
> reconnections
> is non-zero (indicating that the tcp session to the server died).
I don't see this, do I need CONFIG_CIFS_STATS for seeing it?
> Any chance you could do an ethereal network trace of the failure (perhaps
> on the server, if the client is hanging) so we could see the
> last request (presumably a read) that the client sent (and whether the
> server responded).
>
> Also is it possible to build your kernel with some of the debugging options
> turned on (e.g. "Debug Memory allocations" and "mutex debugging, deadlock
> detection" and
> "detect soft lockups") to see if we are overwritting memory and hitting an
> obscure
> deadlock.
Both are now on my TODO list.
> It would also be helpful, if the problem turns out to be non-obvious, to
> track this via a new bug # in bugzilla.samba.org
OK.
> Steve French
cu
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: February 15, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20060215222757.GD5066@xxxxxxxxx>
References:
<20060215222757.GD5066@xxxxxxxxx>
> Thanks, this patch works fine for me
Yes - that is as expected and we appreciate the confirmation.
> But even with this patch applied, I had a freeze in the
> non-forcedirectio case, although much later than usual.
> There seems to be more than one bug. :-(
That is also as expected - it might be one it might be two bugs. Seeing EAGAIN coming back either from the socket API or (even after many retries) or perhaps due to a dead socket ... (server bug? network hardware?). The client usually handles those, closes/reopens the socket, retries the read etc. but perhaps we have a bug in an error path in cifs_readpages or SMBRead
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: February 15, 2006
From: Adrian Bunk <bunk@xxxxxxxxx>
In-reply-to:
<1139946851.9961.28.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<20050721115604.GB3160@xxxxxxxxx> <OF31F3CBF1.99DB2B76-ON87257046.0068484B-86257046.0068A410@xxxxxxxxxx> <20050722191457.GL3160@xxxxxxxxx> <43F20EC0.8090305@xxxxxxxxxx> <20060214171713.GA3513@xxxxxxxxx> <1139946851.9961.28.camel@xxxxxxxxxxxxxxxxxxxxxxx>
On Tue, Feb 14, 2006 at 01:54:11PM -0600, Dave Kleikamp wrote:
>...
> I wasn't able to trace it to an exact line of code, but I think I see
> what the problem is.
>
> This patch moves the copy_to_user from smb_read_data after the test
> whether smb_read_data is null. It's good not to dereference a pointer
> if you have a reason to test it for null afterward.
>
> This patch has not been compiled or tested.
>...
Thanks, this patch works fine for me and after disassembling it seems
you've found exactly the place where the kernel Oops'ed for me in the
forcedirectio case.
But even with this patch applied, I had a freeze in the
non-forcedirectio case, although much later than usual.
There seems to be more than one bug. :-(
I'm currently trying whether there are still any problems in the
forcedirectio case, and I'll report back as soon as I am able to provide
any additional information.
> David Kleikamp
cu
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: February 15, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<20060214135016.GC10701@xxxxxxxxx>
References:
<20060214135016.GC10701@xxxxxxxxx>
> I'm connecting to a Samba server. > > Copying data to the server works without any problems. > > When trying to copy some GB from the server, my computer completely > frezzes after some 100 MB. This is reproducible. > > "Complete freeze" is: > - no reaction to any input, even when I was in the console the magic > SysRq key is not working > - if XMMS was playing, the approx. half a second of the song that was > playing at the time when it happened is played in an endless loop by > the sound chip > > I once switched to the console waiting for the crash, and I saw the > following messages: > CIFS VFS: No response to cmd 46 mid 5907 > CIFS VFS: Send error in read = -11 > > There are no other CIFS messages in my logs, and the messages above > didn't make it into the logs (there's nothing recorded in the logs at > the time of the crashes). > > I tried kernel 2.6.16-rc2 and 2.6.16-rc3. > > 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.21a-4 package from Debian. > > It doesn't occur in 2.6.15.4, because with this kernel (and AFAIR also > with older kernels) my computer refuses to mount this share. > > Mounting the same share with smbfs works without big problems (on some > rare occassions the connection might become stale and I have to umount > and remount the share, but this is rare and it never affects the > stability of my computer). > > 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 Command 46 is an SMB Read. IIRC send error in read -11 is EAGAIN which could indicate that the socket is congested and stayed congested but normally that would be accompanied by a "sends on socket stuck for x seconds" Could you check /proc/fs/cifs/DebugData and see if the number of reconnections is non-zero (indicating that the tcp session to the server died). Any chance you could do an ethereal network trace of the failure (perhaps on the server, if the client is hanging) so we could see the last request (presumably a read) that the client sent (and whether the server responded). Also is it possible to build your kernel with some of the debugging options turned on (e.g. "Debug Memory allocations" and "mutex debugging, deadlock detection" and "detect soft lockups") to see if we are overwritting memory and hitting an obscure deadlock. It would also be helpful, if the problem turns out to be non-obvious, to track this via a new bug # in bugzilla.samba.org Steve French Senior Software Engineer Linux Technology Center - IBM Austin phone: 512-838-2294 email: sfrench at-sign us dot ibm dot com
Date: February 15, 2006
From: Matthew Linehan <mlinehan@xxxxxxxxxxxx>
In-reply-to:
<OFCDB46318.A5201092-ON87257116.000C3D25-86257116.000C7F6D@ us.ibm.com>
References:
<6.1.2.0.0.20060214142650.024ae920@xxxxxxxxxxxxxxxx> <OFCDB46318.A5201092-ON87257116.000C3D25-86257116.000C7F6D@xxxxxxxxxx> <OFCDB46318.A5201092-ON87257116.000C3D25-86257116.000C7F6D@ us.ibm.com>
References:
<6.1.2.0.0.20060214142650.024ae920@xxxxxxxxxxxxxxxx> <OFCDB46318.A5201092-ON87257116.000C3D25-86257116.000C7F6D@xxxxxxxxxx>
At 09:18 PM 2/14/2006, Steven French wrote:
> I have a Windows NT4 Server SP6 share that I am mounting from Linux (Kernel> = 2.6.13-15.8-default (Suse 10.0)). I have tried using both SMBFS and > CIFS. Both have problems... > > I tired smbfs first, my fstab line:> //server/alidata /mnt/alidata smbfs username=mlinehan%password,fmask=777 0 0 > Mostly works, but I get random input/output errors while copying files, and > sometimes smbfs hangs locking up any process that accesses the mounted share> /var/log/messages shows lots of smb timeouts, and the occasional invalid > NBT packet received > The invalid NBT packets seem to cause smbfs to hang.. > ifconfig shows 0 errors, 0 dropped, 0 overruns for both the TX and RX > statistics for the ethernet interface Not sure what the smbfs problem is, but cifs does handle a reasonable subset of the old style NT4 operations (not ideal NT4 support but good enough for casual use). > I tried cifs second, my fstab line is: > //server/alidata /mnt/alidata cifs> user=mlinehan#password,uid=mlinehan,gid=users,file_mode=0777,dir_mode=0777 0 0> The share mounts ok, I can read files just fine, but attempts to write > files, randomly fails leaving a file on the NT server in a state that > cannot be accessed by anyone. The files appear to have no owner, cannot be > deleted or accessed by the NT administrator. When administrator attempts > to take ownership of the file, he gets accessed denied. NT server managerI vaguely remember CIFS setting "delete-on-close" on NT4 files prior to CIFS version 1.31 which might be what is causing this problem. Versions above cifs 1.32 should be fine.
cat /proc/fs/cifs/DebugData
Display Internal CIFS Data Structures for Debugging
----------------------------------------------------------------------------
CIFS Version 1.35
Servers:
1) Name: 192.168.168.1 Domain: SKYNET Mounts: 1 ServerOS: Windows NT 4.0
ServerNOS: NT LAN Manager 4.0 Capabilities: 0x43fd
SMB session status: 1 TCP status: 1
Local Users to Server: 1 SecMode: 0x3 Req Active: 0
MIDS:
Shares:
1) \\server\alidata Uses: 1 Type: NTFS Characteristics: 0x20 Attributes: 0x1f
PathComponentsMax: 255 Status: 1 type: DISK
A.L.I. Engineering
mlinehan@xxxxxxxxxxxx
Phone: 614-851-1100
Fax: 614-851-1121
Date: February 15, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<6.1.2.0.0.20060214142650.024ae920@xxxxxxxxxxxxxxxx>
References:
<6.1.2.0.0.20060214142650.024ae920@xxxxxxxxxxxxxxxx>
> I have a Windows NT4 Server SP6 share that I am mounting from Linux (Kernel
> = 2.6.13-15.8-default (Suse 10.0)). I have tried using both SMBFS and
> CIFS. Both have problems...
>
> I tired smbfs first, my fstab line:
> //server/alidata /mnt/alidata smbfs username=mlinehan%password,fmask=777 0 0
> Mostly works, but I get random input/output errors while copying files, and
> sometimes smbfs hangs locking up any process that accesses the mounted share
> /var/log/messages shows lots of smb timeouts, and the occasional invalid
> NBT packet received
> The invalid NBT packets seem to cause smbfs to hang..
> ifconfig shows 0 errors, 0 dropped, 0 overruns for both the TX and RX
> statistics for the ethernet interface
Not sure what the smbfs problem is, but cifs does handle a reasonable subset
of the old style NT4 operations (not ideal NT4 support but good enough for
casual use).
> I tried cifs second, my fstab line is:
> //server/alidata /mnt/alidata cifs
> user=mlinehan#password,uid=mlinehan,gid=users,file_mode=0777,dir_mode=0777 0 0
> The share mounts ok, I can read files just fine, but attempts to write
> files, randomly fails leaving a file on the NT server in a state that
> cannot be accessed by anyone. The files appear to have no owner, cannot be
> deleted or accessed by the NT administrator. When administrator attempts
> to take ownership of the file, he gets accessed denied. NT server manager
I vaguely remember CIFS setting "delete-on-close" on NT4 files prior to CIFS version 1.31 which
might be what is causing this problem. Versions above cifs 1.32 should be fine.
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: February 15, 2006
From: Steven French <sfrench@xxxxxxxxxx>
Shaggy looks like he caught a problem, but I would like to find out if this helped (probably would only matter for the "forcedirectio" case).
Although there probably is an underlying issue (dropped tcp connection, network and/or server problem) which caused the null response obviously the cifs client should not hang or oops in those cases and getting the fix upstream (even for the rarer forcedirectio case) is important. if this helped that one case.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
----- Forwarded by Steven French/Austin/IBM on 02/14/2006 08:07 PM -----
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 02/14/2006 01:54 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: February 14, 2006
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
In-reply-to:
<20060214171713.GA3513@xxxxxxxxx>
References:
<20050721115604.GB3160@xxxxxxxxx> <OF31F3CBF1.99DB2B76-ON87257046.0068484B-86257046.0068A410@xxxxxxxxxx> <20050722191457.GL3160@xxxxxxxxx> <43F20EC0.8090305@xxxxxxxxxx> <20060214171713.GA3513@xxxxxxxxx>
On Tue, 2006-02-14 at 18:17 +0100, Adrian Bunk wrote:
> On Tue, Feb 14, 2006 at 11:09:20AM -0600, Steve French wrote:
>
> > Adrian,
>
> Hi Steve,
>
> > If your problem turns out to be serious - I do want to find a way to
> > solve this before 2.6.16 goes out
>
> :-)
>
> > A couple of other datapoints that might be helpful ... Although we don't
> > know for sure that the hang is related to
> > SMB read (despite the EAGAIN warning logged on a read) - it might be
> > useful to know whether the problem
> > occurred when mount option "forcedirectio" is specified (since reads in
> > that case will bypass the pagecache).,
>
> With forcedirectio, it's still failing after some time (this time not
> until nearly 1 GB was transferred), but instead of killing the machine
> it's giving a useful error message ("Process mc" since I was copying
> with GNU Midnight Commander):
>
> Feb 14 18:03:16 r063144 kernel: CIFS VFS: No response to cmd 46 mid 42374
> Feb 14 18:03:16 r063144 kernel: CIFS VFS: Send error in read = -11
> Feb 14 18:03:19 r063144 kernel: Unable to handle kernel NULL pointer
> dereference at virtual address 00000031
> Feb 14 18:03:19 r063144 kernel: printing eip:
> Feb 14 18:03:19 r063144 kernel: c0182caa
> Feb 14 18:03:19 r063144 kernel: *pde = 00000000
> Feb 14 18:03:19 r063144 kernel: Oops: 0000 [#1]
> Feb 14 18:03:19 r063144 kernel: Modules linked in:
> Feb 14 18:03:19 r063144 kernel: CPU: 0
> Feb 14 18:03:19 r063144 kernel: EIP: 0060:[cifs_user_read+319/539] Not
> tainted VLI
> Feb 14 18:03:19 r063144 kernel: EFLAGS: 00210296 (2.6.16-rc3 #1)
> Feb 14 18:03:19 r063144 kernel: EIP is at cifs_user_read+0x13f/0x21b
> Feb 14 18:03:19 r063144 kernel: eax: fffffff5 ebx: 0001b746 ecx: 00000000
> edx: 00000000
> Feb 14 18:03:19 r063144 kernel: esi: 00002000 edi: fffffff5 ebp: d3be5b20
> esp: c842ff38
> Feb 14 18:03:19 r063144 kernel: ds: 007b es: 007b ss: 0068
> Feb 14 18:03:19 r063144 kernel: Process mc (pid: 29402, threadinfo=c842e000
> task=cdbfe030)
> Feb 14 18:03:19 r063144 kernel: Stack: <0>00002000 08dd2000 00000000 c842ff70
> c842ff6c c842ff68 00002000 da1725e0
> Feb 14 18:03:19 r063144 kernel: 00000000 c21f9920 c5224aa0 08184fb0
> 00000000 00000000 00000000 d3be5b20
> Feb 14 18:03:19 r063144 kernel: 00002000 c0182b6b 08184fb0 c013d736
> c842ffa4 d3be5b20 fffffff7 08184fb0
> Feb 14 18:03:19 r063144 kernel: Call Trace:
> Feb 14 18:03:19 r063144 kernel: [cifs_user_read+0/539]
> cifs_user_read+0x0/0x21b
> Feb 14 18:03:19 r063144 kernel: [vfs_read+125/223] vfs_read+0x7d/0xdf
> Feb 14 18:03:19 r063144 kernel: [sys_read+60/99] sys_read+0x3c/0x63
> Feb 14 18:03:19 r063144 kernel: [sysenter_past_esp+84/117]
> sysenter_past_esp+0x54/0x75
> Feb 14 18:03:19 r063144 kernel: Code: 18 50 8d 44 24 20 50 8d 44 24 28 50 8b
> 54 24 44 89 d8 ff 72 04 ff 32 56 8b 54 24 28 e8 4b 6d ff ff 8b 54 24 34 89 c7
> 8b 4c 24 38 <0f> b7 42 31 8d 54 02 04 8b 44 24 2c e8 ce 97 01 00 83 c4 18 85
> Feb 14 18:03:19 r063144 kernel: <3> CIFS VFS: Send error in Close = -9
I wasn't able to trace it to an exact line of code, but I think I see
what the problem is.
This patch moves the copy_to_user from smb_read_data after the test
whether smb_read_data is null. It's good not to dereference a pointer
if you have a reason to test it for null afterward.
This patch has not been compiled or tested.
Signed-off-by: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
diff -urp linux-2.6.16-rc3/fs/cifs/file.c linux/fs/cifs/file.c
--- linux-2.6.16-rc3/fs/cifs/file.c 2006-02-13 07:28:51.000000000 -0600
+++ linux/fs/cifs/file.c 2006-02-14 13:45:09.000000000 -0600
@@ -1441,14 +1441,16 @@ ssize_t cifs_user_read(struct file *file
current_read_size, *poffset,
&bytes_read, &smb_read_data,
&buf_type);
- pSMBr = (struct smb_com_read_rsp *)smb_read_data;
- if (copy_to_user(current_offset,
- smb_read_data + 4 /* RFC1001 hdr */
- + le16_to_cpu(pSMBr->DataOffset),
- bytes_read)) {
- rc = -EFAULT;
- }
if (smb_read_data) {
+ pSMBr = (struct smb_com_read_rsp *)
+ smb_read_data;
+ if (copy_to_user(current_offset,
+ smb_read_data +
+ 4 + /* RFC1001 hdr */
+ le16_to_cpu(pSMBr->DataOffset),
+ bytes_read)) {
+ rc = -EFAULT;
+ }
if(buf_type == CIFS_SMALL_BUFFER)
cifs_small_buf_release(smb_read_data);
else if(buf_type == CIFS_LARGE_BUFFER)
--
David Kleikamp
IBM Linux Technology Center
Date: February 14, 2006
From: Lee Revell <rlrevell@xxxxxxxxxxx>
In-reply-to:
<Pine.LNX.4.61.0602141911470.32490@xxxxxxxxxxxxxxx>
References:
<20060214135016.GC10701@xxxxxxxxx> <Pine.LNX.4.61.0602141911470.32490@xxxxxxxxxxxxxxx>
On Tue, 2006-02-14 at 19:12 +0100, Jan Engelhardt wrote: > >"Complete freeze" is: > >[..] > > is played in an endless loop by the sound chip > > Sounds like a portion of code disabled interrupts? Anything that locks the machine while sound is playing will cause the last period of audio to repeat in an endless loop, because the DMA engine keeps running but the soundcard isn't getting new data. It's not specific to interrupt disabling. Isn't it fortunate that network cards don't work this way? ;-) Lee
Date: February 14, 2006
From: Jan Engelhardt <jengelh@xxxxxxxxxxxxxxx>
In-reply-to:
<20060214135016.GC10701@xxxxxxxxx>
References:
<20060214135016.GC10701@xxxxxxxxx>
>"Complete freeze" is: >[..] > is played in an endless loop by the sound chip Sounds like a portion of code disabled interrupts? Jan Engelhardt --
Date: February 14, 2006
From: Marc Koschewski <marc@xxxxxxxxxxxxxxx>
In-reply-to:
<20060214135016.GC10701@xxxxxxxxx>
References:
<20060214135016.GC10701@xxxxxxxxx>
* Adrian Bunk <bunk@xxxxxxxxx> [2006-02-14 14:50:16 +0100]:
> Hi Steve,
>
> I do obvserve the following on my i386 computer:
>
> I'm connecting to a Samba server.
>
> Copying data to the server works without any problems.
>
> When trying to copy some GB from the server, my computer completely
> frezzes after some 100 MB. This is reproducible.
>
> "Complete freeze" is:
> - no reaction to any input, even when I was in the console the magic
> SysRq key is not working
> - if XMMS was playing, the approx. half a second of the song that was
> playing at the time when it happened is played in an endless loop by
> the sound chip
>
Adrian,
I just copied some ~2 GB file and my system is running OK. The share is
a CIFS on a Samba-Server of MacOS X.
Marc
Date: February 14, 2006
From: Adrian Bunk <bunk@xxxxxxxxx>
Hi Steve,
I do obvserve the following on my i386 computer:
I'm connecting to a Samba server.
Copying data to the server works without any problems.
When trying to copy some GB from the server, my computer completely
frezzes after some 100 MB. This is reproducible.
"Complete freeze" is:
- no reaction to any input, even when I was in the console the magic
SysRq key is not working
- if XMMS was playing, the approx. half a second of the song that was
playing at the time when it happened is played in an endless loop by
the sound chip
I once switched to the console waiting for the crash, and I saw the
following messages:
CIFS VFS: No response to cmd 46 mid 5907
CIFS VFS: Send error in read = -11
There are no other CIFS messages in my logs, and the messages above
didn't make it into the logs (there's nothing recorded in the logs at
the time of the crashes).
I tried kernel 2.6.16-rc2 and 2.6.16-rc3.
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.21a-4 package from Debian.
It doesn't occur in 2.6.15.4, because with this kernel (and AFAIR also
with older kernels) my computer refuses to mount this share.
Mounting the same share with smbfs works without big problems (on some
rare occassions the connection might become stale and I have to umount
and remount the share, but this is rare and it never affects the
stability of my computer).
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: February 13, 2006
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
In-reply-to:
<43F09F62.4090803@xxxxxxxxxxxxx>
References:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx> <43F08DBC.4060202@xxxxxxxxxxxxx> <43F099A8.1010902@xxxxxxxxxxxxx> <1139842611.10036.17.camel@xxxxxxxxxxxxxxxxxxxxxxx> <43F09F62.4090803@xxxxxxxxxxxxx>
On Mon, 2006-02-13 at 16:01 +0100, Steven Scholz wrote: > >> Other fs drivers work without swap support. > >> Maybe it's possible to implement writepages() without > >> pagevec_lookup_tag() ... > > It may be possible, but not optimal. This isn't an issue in the > > mainline kernel, but only when building the latest cifs code on older > > kernels. > > Ok. So if I remove cifs_writepages() (cause I have no swap) then > cifs_writepage() will be used instead which is less efficient but should > work well. Right? I think Steve already answered this, but right. It really has nothing to do with swap. Those symbols have only recently been exported by the kernel and were not available to modules until very recently. Other options are to patch to kernel to export those symbols, or to build cifs into the kernel rather than as a module. -- David Kleikamp IBM Linux Technology Center
Date: February 13, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<43F09BAF.7050300@xxxxxxxxxxxxx>
References:
<43F09BAF.7050300@xxxxxxxxxxxxx>
Yes - You have to remove that line - there is a path in which iov array is only length one so setting iov[1] would be bad.
Note that cifs_writepages is easily removed which is harmless for older kernels and has no functional difference (other than the drop from 52K to 4K writes can slow sequential writes down by perhaps 5-40% at least to lightly loaded servers; the actual difference depends on lots of factors including the network speed)
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
02/13/2006 08:46 AM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: February 13, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<8B32D6CE8525A94F82C1B6CD552D9637410AFA@xxxxxxxxxxxxx>
References:
<8B32D6CE8525A94F82C1B6CD552D9637410AFA@xxxxxxxxxxxxx>
> decided to go only the plaintext password way. I tested my server with the
> smb kernel module an it worked (at least the password part). Now I wanted
> to test the server with the cifs kernel module and I observed, that the
> server receives always a somewhat encrypted password (I think it gets
> encrypted with SMBencrypt(), because I receive a 24 byte value. The
> server correctly sends 0x01 as security mode in the Negotiate message).
> I saw that you did a lot of work for the cifs module so I decided to
> ask you directly if it is intended that the module sends an encrypted
> pwd even if the server requested a plaintext pwd.
It would be very easy to support.
I decided to turn off plain text passwords (and lanman passwords) as they are so insecure and users might not realize when a rogue server would be "downgraded" to force plain text from the client (or very weak passwords). I don't know if that is the right decision - I am second guessing that since lanman hash is necessary for finish up of support for os/2 and windows 95 and there are some valid cases in which the physical network is secure and plain text passwords to the server might be ok. Perhaps the best alternative is add a
CONFIG_WEAK_PASSWORDS
in make menuconfig, and put the lanman and plain text password support in that ifdef (mostly in fs/cifs/connect.c, although I have been toying with a new ntlmssp.c which might contain a session setup rewrite - as session setup for cifs is verbose and could use cleaning up as well as the needed fixes for ntlmv2). In addition if "CONFIG_WEAK_PASSWORDS" is set, cifs could export a /proc/fs/cifs/AllowWeakPasswords which would default to one (perhaps set to zero would mean NTLMv2 or Kerberos only, since NTLMv2 is close to complete although Kerberos is not, set to one would indicate allow ntlm or ntlmv2 or kerberos, two would indicate allow lanman or ntlmv or ntlmv2 or kerveros, 3 would be allow plain text etc.)
Thoughts?
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: February 13, 2006
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<1139842611.10036.17.camel@xxxxxxxxxxxxxxxxxxxxxxx>
References:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx> <43F08DBC.4060202@xxxxxxxxxxxxx> <43F099A8.1010902@xxxxxxxxxxxxx> <1139842611.10036.17.camel@xxxxxxxxxxxxxxxxxxxxxxx>
Dave, >> But why do we need pagevec_lookup_tag() at all? > For better performance, cifs is sending multiple page cache pages to the > server in a single request. >> No other fs driver needs it. (At least a "grep -r" didn't show it.) > cifs is leading edge technology. :-) Actually, reiser4 uses these too, > but it isn't in the mainline kernel yet. Ah. Ok. Understood. >> Other fs drivers work without swap support. >> Maybe it's possible to implement writepages() without >> pagevec_lookup_tag() ... > It may be possible, but not optimal. This isn't an issue in the > mainline kernel, but only when building the latest cifs code on older > kernels. Ok. So if I remove cifs_writepages() (cause I have no swap) then cifs_writepage() will be used instead which is less efficient but should work well. Right? -- Steven Scholz
Date: February 13, 2006
From: Dave Kleikamp <shaggy@xxxxxxxxxxxxxx>
In-reply-to:
<43F099A8.1010902@xxxxxxxxxxxxx>
References:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx> <43F08DBC.4060202@xxxxxxxxxxxxx> <43F099A8.1010902@xxxxxxxxxxxxx>
On Mon, 2006-02-13 at 15:37 +0100, Steven Scholz wrote: > Steven, > > > On embedded systems with no "Support for paging of anonymous memory > > (swap)" the build (and insmod) will fail with > > > > *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined! > > *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined! > > BTW: > Excuse my ignorance. I have no deep inside neither into fs nor mm stuff. > But why do we need pagevec_lookup_tag() at all? For better performance, cifs is sending multiple page cache pages to the server in a single request. > No other fs driver needs it. (At least a "grep -r" didn't show it.) cifs is leading edge technology. :-) Actually, reiser4 uses these too, but it isn't in the mainline kernel yet. > Other fs drivers work without swap support. > Maybe it's possible to implement writepages() without > pagevec_lookup_tag() ... It may be possible, but not optimal. This isn't an issue in the mainline kernel, but only when building the latest cifs code on older kernels. > But again: I have no deeper understanding of the fs internas. -- David Kleikamp IBM Linux Technology Center
Date: February 13, 2006
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<OF0ADA3D2D.8A46CE7C-ON87257103.0054D0D6-86257103.0054EB39@xxxxxxxxxx>
References:
<OF0ADA3D2D.8A46CE7C-ON87257103.0054D0D6-86257103.0054EB39@xxxxxxxxxx>
Steven French wrote: > > This is probably closer to what you want: > http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40a-2.6.13.tar.gz > There are two minor, but important fixes that are not in the various 1.40a > tar.gz's (that are in the cifs development tree, and hopefully mainline > soon as soon as Linus gets back) > > The one line fix removing the set which can go off the end of the stack in > transport.c (iov[1].len = 0) and the set of the default wsize to 52K (for > servers which support large write X) are not in the various > cifs1.40a.tar.gz Did you mean this one? --- a/fs/cifs/transport.c +++ b/fs/cifs/transport.c @@ -498,7 +498,6 @@ SendReceive2(const unsigned int xid, str else *pRespBufType = CIFS_SMALL_BUFFER; iov[0].iov_len = receive_len + 4; - iov[1].iov_len = 0; dump_smb(midQ->resp_buf, 80); /* convert the length into a more usable form */ Not sure if I understood correctly. Do we need the line "iov[1].iov_len = 0;". Or do we have to remove that line? -- Steven Scholz
Date: February 13, 2006
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<43F08DBC.4060202@xxxxxxxxxxxxx>
References:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx> <43F08DBC.4060202@xxxxxxxxxxxxx>
Steven, > On embedded systems with no "Support for paging of anonymous memory > (swap)" the build (and insmod) will fail with > > *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined! > *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined! BTW: Excuse my ignorance. I have no deep inside neither into fs nor mm stuff. But why do we need pagevec_lookup_tag() at all? No other fs driver needs it. (At least a "grep -r" didn't show it.) Other fs drivers work without swap support. Maybe it's possible to implement writepages() without pagevec_lookup_tag() ... But again: I have no deeper understanding of the fs internas. -- Steven Scholz
Date: February 13, 2006
From: Steven Scholz <steven.scholz@xxxxxxxxxxxxx>
In-reply-to:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx>
References:
<OF8B5B6E7A.0203134C-ON872570F5.00017267-862570F5.000194C4@xxxxxxxxxx>
Steven, > I put a 1.40 tar.gz for the cifs kernel code on > http://svn.samba.org/samba/ftp/cifs-cvs/cifs-1.40.tar.gz It looks like cifs_writepages() in fs/cifs/file.c in no longer wrapped in CONFIG_CIFS_EXPERIMENTAL in your recent 1.40 releases. This is bad. On embedded systems with no "Support for paging of anonymous memory (swap)" the build (and insmod) will fail with *** Warning: "pagevec_lookup_tag" [fs/cifs/cifs.ko] undefined! *** Warning: "__pagevec_release" [fs/cifs/cifs.ko] undefined! In earlier releases (1.39) cifs_writepages() was wrapped in CONFIG_CIFS_EXPERIMENTAL. Thus I could build cifs without experimental stuff, i.e. without calls of pagevec functions. As I wrote in a previous mail IMHO functions in cifs that need swap support should be wrapped in #ifdef's, i.e. compiled in conditionally. So either use CONFIG_CIFS_EXPERIMENTAL or (which I think is better) CONFIG_SWAP directly. Would you like patch? -- Steven Scholz
Date: February 09, 2006
From: Steven French <sfrench@xxxxxxxxxx>
In-reply-to:
<7f3879500602082128p14dc186djbb65b38c2f19c63a@xxxxxxxxxxxxxx>
References:
<7f3879500602082128p14dc186djbb65b38c2f19c63a@xxxxxxxxxxxxxx>
The most up to date version of the Linux cifs client is on kernel.org (downloadable via git from linux-2.6.git tree). Currently cifs in mainline 2.6.16-rc2 Linux kernel matches the version in the development tree.
It has been backported to earlier 2.6 kernels (and there is an older version for 2.4). It has also been ported to user space as a library although I currently don't have a version of that on the download site.
Steve French
Senior Software Engineer
Linux Technology Center - IBM Austin
phone: 512-838-2294
email: sfrench at-sign us dot ibm dot com
Vijaya Bhaskar V <bhasvij@xxxxxxxxx>
Sent by: linux-cifs-client-bounces+sfrench=us.ibm.com@xxxxxxxxxxxxxxx 02/08/2006 11:28 PM |
|
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: February 09, 2006
From: Vijaya Bhaskar V <bhasvij@xxxxxxxxx>
_______________________________________________ linux-cifs-client mailing list linux-cifs-client@xxxxxxxxxxxxxxx https://lists.samba.org/mailman/listinfo/linux-cifs-client
Date: February 08, 2006
From: "William Law" <law@xxxxxxxxxxxxxx>
Hi, I'm using RHEL4 with the latest stable kernel as of yesterday, 2.6.15.3 with the new CIFS code(s) because I couldn't get this to work with the older versions, either. We have a domain based MS-DFS root and a stand alone MS-DFS duplicate of the same root. I can successfully mount the share if I point to the stand alone root or the shares that are used for the domain based root, but not the domain root itself. I'm using the syntax mount -t cifs //servername/sharename /mnt/sharename -o user=username. It appears that domain based dfs is not supported, and that is fine - but I did want to confirm this. Anyway, the real problem is that with any of the roots, I can not get past the initial mount point. Changing to another directory is successful, but when I do ls, I just get the same listing as the mounted root - I can't get past the initial level! A separate issue is that I haven't been able to test or try to use the Kerberos support. I've tried using mount -t cifs //servername/sharename /mnt/sharename -o sec=krb5 but I just get the help. Yeah, I did compile the experimental options into the kernel module. I'm hoping that they syntax is wrong, but I honestly don't have a clue. I'm attaching a separate message that I have posted to samba and cifs-clients about smbclient, where I am having similar but not exactly the same problems. We'd really like to be able to mount these shares from our linux nodes. Any help would be greatly appreciated! Thanks, Will -- Previous subject: [Samba] DFS redirection to sub-folders beyond share Hi, I already posted this to smb-clients, but I believe that is a very low volume list. We have a very complicated dfs root. Now I'm not positive that this is how we should have done things, but it works very well with Windows clients, so it hasn't been thought about here. This does not work with smbclient or smbmount. I'm using freshly built smbclient from Samba 3.0.21a. Anyway, here is the issue. We have a very large namespace via one root that is currently active directory based. We have many dfs links that work like this. Let's say our domain is called DOMAIN, and the root is called dfs. \\DOMAIN\dfs <file:///\\DOMAIN\dfs> is then mapped to an empty folder. >From there, we have many dfs links, such as: Users\testuser which is mapped in DFS to \\fileserver1\share\Users\testuser <file:///\\fileserver1\share\Users\testuser> , which works easily in windows to seamless take the user who access \\domain\dfs\users\testuser <file:///\\domain\dfs\users\testuser> to the folder \\fileserver1\share\users\testuser <file:///\\fileserver1\share\users\testuser> . This does NOT work under smbclient. I think that we just need to be able to map users to something beyond the actual share. It looks like it could be fixed by modifying the code to handle the slashes correctly (see the error below). Here is the log from smbclient with the -d 3 debugging option: sh-3.00$ smbclient //tc.cornell.edu/tc -k -d 3 lp_load: refreshing parameters Initialising global parameters params.c:pm_process() - Processing configuration file "/etc/samba/smb.conf" Processing section "[global]" Can't find include file /etc/samba/smb.conf. added interface ip=128.84.31.152 bcast=128.84.31.255 nmask=255.255.255.0 Client started (version 3.0.21a). resolve_hosts: Attempting host lookup for name tc.cornell.edu<0x20> Connecting to 128.84.5.22 at port 445 Doing spnego session setup (blob length=111) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcdc04$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST OS=[Windows Server 2003 3790 Service Pack 1] Server=[Windows Server 2003 5.2] resolve_hosts: Attempting host lookup for name tc.cornell.edu<0x20> Connecting to 128.84.43.250 at port 445 Doing spnego session setup (blob length=111) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcdc03$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST dos_clean_name [] resolve_hosts: Attempting host lookup for name ctcfsrv10<0x20> Connecting to 128.84.29.24 at port 445 Doing spnego session setup (blob length=113) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv10$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST resolve_hosts: Attempting host lookup for name ctcfsrv10<0x20> Connecting to 128.84.29.24 at port 445 Doing spnego session setup (blob length=113) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv10$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST dos_clean_name [] resolve_hosts: Attempting host lookup for name CTCFSRV11<0x20> Connecting to 128.84.29.25 at port 445 Doing spnego session setup (blob length=113) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv11$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST resolve_hosts: Attempting host lookup for name CTCFSRV11<0x20> Connecting to 128.84.29.25 at port 445 Doing spnego session setup (blob length=113) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv11$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST dos_clean_name [] dos_clean_name [] smb: \> cd cbsu dos_clean_name [\cbsu\] dos_clean_name [\cbsu\\] resolve_hosts: Attempting host lookup for name ctcfsrv6.tc.cornell.edu<0x20> Connecting to 128.84.40.20 at port 445 Doing spnego session setup (blob length=112) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv6$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST resolve_hosts: Attempting host lookup for name ctcfsrv6.tc.cornell.edu<0x20> Connecting to 128.84.40.20 at port 445 Doing spnego session setup (blob length=112) got OID=1 2 840 48018 1 2 2 got OID=1 2 840 113554 1 2 2 got OID=1 2 840 113554 1 2 2 3 got OID=1 3 6 1 4 1 311 2 2 10 got principal=ctcfsrv6$@TC.CORNELL.EDU Doing kerberos session setup Ticket in ccache[FILE:/tmp/krb5cc_16777216_onPqOV] expiration Wed, 01 Feb 2006 19:25:27 EST dos_clean_name [] dos_clean_name [] dos_clean_name [\CTCFSRV11\tc\cbsu] dos_clean_name [\cbsu] smb: \cbsu\> cd / dos_clean_name [\] dos_clean_name [\\] smb: \> cd users\law dos_clean_name [\users\law\] dos_clean_name [\users\law\\] resolve_hosts: Attempting host lookup for name ctcfsrv9.tc.cornell.edu\tc_q\users<0x20> Connection to ctcfsrv9.tc.cornell.edu\tc_q\users failed Unable to follow dfs referral [//ctcfsrv9.tc.cornell.edu\tc_q\users/law] cd \users\law\: NT_STATUS_PATH_NOT_COVERED Thanks! William Law
