Samba caching directory handles? (Writes to incorrect home dir)

Andrew Bartlett abartlet at
Tue May 15 12:47:43 GMT 2001

James Sutherland wrote:
> On Tue, 15 May 2001, Andrew Bartlett wrote:
> > James Sutherland wrote:
> > > On Tue, 15 May 2001, Andrew Bartlett wrote:
> > >
> > > > What I am wondering is if samba does any caching of directory handles or
> > > > the like, and whether samba could be mis-translating //servername/homes
> > > > to the wrong user, using the directory from a previous user.  Is this at
> > > > all possible?
> > >
> > > IIRC, Windows does this: when a new user logs on, it finds a cached
> > > "\\servername\homes" connection, and continues to use that. ISTR there's a
> > > caveat about this in the docs - something along the lines of "don't use
> > > \\servername\home for a home directory mapped to /home/%U because Windows
> > > will cache the first user's \\server\home and reuse it for the next user"?
> >
> > In this case the connection (session setup) is over, as the utmp support
> > shows that the vuid has been invalidated, and the user logged out.  So
> > its probably not this.
> It is: Windows caches the connection even after you log out. Stupid,
> broken and insecure, but unless you're planning to send Microsoft a patch
> to fix it, I think we're stuck with it :-)

But the connection can't be resumed without another session setup, and
hence another utmp entry.  Can it?

> > > Can you switch to something like \\server\home\username as the home
> > > directory? This will be a nuisance for users - everything becomes
> > > "H:\username" instead of "H:\" - but at least their home directories will
> > > be private again! Alternatively, perhaps you could use \\server\username -
> > > so each user has a different sharename for their home directory?
> >
> > Note that this is not a 'domain logon', its a normal file-share
> > connction, and the drive is successfuly un-mapped when the user hits the
> > 'disconnect' button on our logon applet.
> The drive is unmapped, but Windows doesn't drop the connection: it keeps
> it cached.

Note that the unmmapping is sufficient to avoid the crediential
conflict, and we have no reports of users being able to intentionaly
access the shares of others.  The attempted unmapping is also doing
enough that it fails if there are files open over it.

> > Note also that there are no errors being reported, just mysteriously
> > appering files.  What I am wondering is if somthing is keeping the
> > directory open, and if samba is then accidently pulling this out of the
> > 'cache', and creating a new file in it.
> That's EXACTLY what happens - except it's WINDOWS doing this, not Samba.
> > All the home directories are mod 0700, as a matter of note.
> >
> > Also, changing how this works is not an option - we have a fairly large
> > number of users, and this is how they expect it to work.  We have them
> > trained...
> The "feature" of \\server\homes doesn't work properly, and since this is a
> Windows bug not a Samba one, there's nothing that can be done. Either
> change to using \\server\username (which should be transparent, at least
> if you're using something like NET USE /HOME) or put up with Windows
> occasionally getting different users mixed up.

These are NOT domain logons, they are file-share connects from NT
machines in a compleatly different administrative domain.  

In any case, the problem with the \homes thing was the the previous
connection would NOT allow users to access their new profile due to
permissions.  There is no permissions error in this case, the files
appear contary to a mode 0700 directory.

Andrew Bartlett
abartlet at

More information about the samba-technical mailing list