Bug 939 - missing directory entries in searches of a smnfs mount
Summary: missing directory entries in searches of a smnfs mount
Alias: None
Product: Samba 2.2
Classification: Unclassified
Component: smbclient (show other bugs)
Version: 2.2.8a
Hardware: All Linux
: P3 normal
Target Milestone: ---
Assignee: Gerald (Jerry) Carter (dead mail address)
QA Contact:
Depends on:
Reported: 2004-01-03 13:14 UTC by Mitch Crane
Modified: 2005-11-14 09:26 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Mitch Crane 2004-01-03 13:14:14 UTC
Running: SuSE 9.0 Pro - Kernel 2.4.21 - Samba 2.2.8a and 3.0.1-14
Occured with Redhat 9 2.4.x kernels also.

On a box runninng XP Pro (fully up to date as of Jan 3rd, 2003), I have a shared
folder which contains 130+ subdirectories. This share is mounted on my linux box
from '/etc/smbfstab', but some directories do not show up in directory listings.
It's never more than one, and which one varies, but generally seems to be in or
near the last half of the listing. As a test, I can do 'ls -l | wc -l' and the
number will frequently be 1 less than it should be. The same test on a directory
with over 700 files in it I gave as many as 9 missing entries.

When I first noticed the problem I was running Redhat 9. Now I'm running SuSE 9
and the problem persists. I've also tried Samba 3.0.1, but that didn't seem to
make any difference.

I'm guessing this is an issue with smbfs mounts, because I can do 'smbclient
//some-server/blah -U user%pass -c dir' and I don't get any missing directories
or files.

Here appear to be similar reports, but no solutions:


Some of the above reports are pretty old which makes me wonder why more people
haven't run into the problem or if there's some kind of weird system
combinations which cause it.

What I know:

Directories with fewer items don't have this problem.
The larger the directory, the more missing entries.

Following up...

After working well for a day or so, my smbfs directory entries began to "show up
missing" more frequently, so I ran ethereal on the Windows box and captured 2
directory listings. One capture was of an ls of the directory which was complete
and the other has a missing entry.

What I found around the problem area was, a FIND_NEXT2 request from my Linux box
which resulted in 1 FIND_NEXT2 response and 2 NBSS continuation messages
containing the entry list up to the missing entry, then another FIND_NEXT2
requests whose response began after the missing entry. In other words, the
Windows machine never sent the directory entry for the missing item (it just
skipped over it), which implies a problem with the Windows (server) side.

From what I can tell, the missing entry is always the entry which should
have been first in a FIND_NEXT2 response, so it's a problem of the FIND_NEXT2
response sometimes being off by one file further into the search than it should
be. With the directory I've been testing it appears to always be a problem the
2nd or 3rd (which is also the last) FIND_NEXT2 command sent to the server. It
may be that it can occur with any FIND_NEXT2 command after the first.

Noting that I never get this problem with 'smbclient //server/share -U user%pass
-c dir' I captured one of those and I can see that the smbclient dir command
does things quite a bit differently. Since I know very little about how the
protocol works, I won't go into all the differences (which may be irrelevant).

As a shot in the dark, I removed Norton Antivirus from the windows machine, just
in case it might be interfering somehow, but that didn't help.
Comment 1 Mitch Crane 2004-01-13 03:25:11 UTC
Upon further testing, 'smbclient //server/share -U user%pass -c dir' is now
missing directory entries as well.
Comment 2 Gerald (Jerry) Carter (dead mail address) 2004-02-17 08:56:00 UTC
Sorry, but the 2.2 is not under development any longer.
If you can reproduce this bug against the latest 3.0 release, 
please reopen this bug and change the version in the report.
Comment 3 Gerald (Jerry) Carter (dead mail address) 2005-11-14 09:26:20 UTC
database cleanup