[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: smbfs problem with 2.2.5
Fuzzy Fox enscribed thusly:
> Steve Dodd <> wrote:

> > I've lost my recent archives for this list, so I don't know the
> > backgound to this :( but I thought a while back there was discussion
> > about an enhanced smbmount that launched a daemon to manage this sort
> > of thing.

> Smbmount has been this way for a long time, including the current
> version, which a previous poster mentions that he is using, and yet
> still sees this problem.

> As another datapoint, I do NOT see this problem at all (Linux 2.2.4,
> Samba 1.9.18p8). However, I don't use passwords on my Win98 shares, so
> either it's because I mount from Win98 instead of WinNT, or because I
> don't use passwords, whereas other people do.

> It would be a lot more helpful if people would give more information
> about their configurations, rather than just say "I see it too, Linux
> sucks." The problem won't be fixed unless we can narrow down the nature
> of the problem. Try mounting password-less shares and see if they
> remount after idling out. Try different Windows OS's to see if there's
> a commonality there.

Something else to try... Most of the reports I have gotten (with
a few exceptions) the password was entered interactively at the password
prompt. There are several other ways to enter the password. One is on
the command line itself, another is through the "PASSWD" or "USER"
environment variables. You can use a script or command line substitution
to avoid having your password show up in your bash history file and the
program munges its own command line so it doesn't show up in ps. If
those work and the password prompt doesn't, that indicates that I still
have a problem in the password caching somewhere...

The few exceptions that I received later reported that they
were mistakenly on 2.0.2, and that made sense. 2.0.3 was suppose to
fix a couple of password caching problems, and it's possible that I
still managed to miss one or two.

One last thing to try - and use this with caution - is to turn on
SMBFS_DEBUG in the smbmount.c program and recompile it. I say use with
caution because this WILL cause autofs and automount to hang if you are
using smbmount with them. With SMBFS_DEBUG disabled, prompts and messages,
which would occur after smbmount goes daemon, are supressed. That can cause
smbmount to "hang" waiting for a response, which it can't get anyways, and
no message showing on the screen. With SMBFS_DEBUG enabled, at least
the messages should show up in the original window. The reason this is
disabled by default is that it is incompatible with automount from autofs
and Peter Anvin and I have not come up with an alternative solution to
the problem other than "don't do that".

Strangely enough... I haven't had anyone get back to me yeah or
nay after instructing them to enable SMBFS_DEBUG. I don't know what THAT

> --
> (Fuzzy Fox) || "Nothing takes the taste out of peanut
> sometimes known as David DeSimone || butter quite like unrequited love."
> || -- Charlie Brown

Michael H. Warfield | (770) 985-6132 |
(The Mad Wizard) | (770) 925-8248 |
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:51    [W:0.055 / U:0.736 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site