samba - Jun 2007 - [3.0.23d] Subdirectories of share root appear empty (sometimes)

Hi.  We're having a bit of a strange problem with Samba, and we're
hoping someone might be able to offer some good advice as it's
exhausted our ideas.  Thanks.

Our office has a SUSE Linux box that we use as a fileserver, using Samba
to expose it to our Windows machines, in the form of three shares.
Sometimes (it's inconsistent but seems to happen several times a week),
one of our computers will stop 'seeing' the contents of the
subdirectories of the root of one of the shares.  When we open the
share in Explorer, the contents of the root appears as expected, but
when we navigate into any subdirectory it appears as empty.  Meanwhile,
we can open the share on another machine, and all the subdirectory
contents appear as expected.

We've observed this problem on one (and only one) of the shares, which
is itself confusing as they're all configured exactly the same.  We've
tried rebooting the Windows machine but the same problem is observed
when it comes back.  We've also tried rebooting the Samba service, but
again the same problem is observed!  If we leave it for long enough,
however, eventually it starts working again.  Our best guess is that
the Windows machine somehow caches some bad data, somehow.

Thus far this problem has only been observed from two of our Windows
machines; one runs 32-bit Windows XP Pro and the other 64-bit Windows
Server 2003.

The Samba log shows everything appearing normal, e.g.:

[2007/06/18 14:07:12, 2] auth/auth.c:check_ntlm_password(309)
   check_ntlm_password:  authentication for user [fred] -> [fred] -> 
fred] succeeded
[2007/06/18 14:07:12, 2] lib/access.c:check_access(323)
   Allowed connection from  (192.168.1.149)
[2007/06/18 14:07:12, 1] smbd/service.c:make_connection_snum(950)
   kronos (192.168.1.149) connect to service CVS initially as user fred 
(uid=1000, gid=100) (pid 18524)
[2007/06/18 14:07:12, 2] smbd/reply.c:reply_tcon_and_X(711)
   Serving CVS as a Dfs root
[2007/06/18 14:10:37, 2] smbd/open.c:open_file(352)
   port opened file cvs.html read=Yes write=No (numopen=3)
[2007/06/18 14:10:47, 2] smbd/close.c:close_normal_file(344)
   port closed file cvs.html (numopen=2)

Our smb.conf file is quite simple:
    workgroup = JAMES_RE
    server string = Office File Server
    hosts allow = 192.168.1. 127.
    printcap name = /etc/printcap
    load printers = no
    log file = /var/log/samba/%m.log
    log level = 2
    max log size = 128

    security = user
    encrypt passwords = yes
    smb passwd file = /etc/samba/smbpasswd
    ssl CA certFile = /usr/share/ssl/certs/ca-bundle.crt
    username map = /etc/samba/smbusers
    socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
    remote announce = 192.168.1.255
    local master = yes
    os level = 128
    domain master = yes
    preferred master = yes
    domain logons = yes
    name resolve order = host bcast
    dns proxy = no
    veto oplock files = /*.pst/ibdata*/ib_logfile*/

[NETLOGON]
    path = /etc/samba
    read only = yes

[homes]
    comment = Home Directories
    browseable = no
    writable = yes
    case sensitive = yes
    force create mode = 0664
    create mode = 0664
    force directory mode = 0775
    directory mode = 0775

[Common]
    comment = Common Directory
    path = /home/Common
    browseable = yes
    read only = no
    force create mode = 0664
    create mode = 0664
    force directory mode = 0775
    directory mode = 0775

[CVS]
    comment = CVS Repository
    path = /home/CVS
    browseable = yes
    read only = no
    force create mode = 0660
    create mode = 0660
    force directory mode = 0770
    directory mode = 0770

Any advice anyone may have on this matter would be much appreciated.
Many thanks,

James.

On Monday 18 June 2007, James Farmer wrote:

Probably nothing to do with your problem but I wonder about some of the 
settings.
> ? ? remote announce = 192.168.1.255
This appears to be the network you are on - why is there a need for a remote 
announce?
> ? ? local master = yes
> ? ? os level = 128
> ? ? domain master = yes
> ? ? preferred master = yes
> ? ? domain logons = yes
> ? ? name resolve order = host bcast
Looks like you're running a domain controller. Probably should use WINS,
make
sure your clients register themselves and "wins" to the "name
resolve order".
     name resolve order = wins host bcast
> ? ? force create mode = 0664
> ? ? create mode = 0664
> ? ? force directory mode = 0775
> ? ? directory mode = 0775
Seems to me that "create mode"/"directory mode" would be
logically mutually
exclusive with "force create mode"/"force directory mode".
Let the force be
with you and remove the non-force directives from your shares.

Of course running a newer version of samba may help as well.

Chris

On Mon, Jun 18, 2007 at 02:59:56PM +0100, James Farmer
wrote:
> Hi.  We're having a bit of a strange problem with Samba, and we're
> hoping someone might be able to offer some good advice as it's
> exhausted our ideas.  Thanks.
> 
> Our office has a SUSE Linux box that we use as a fileserver, using Samba
> to expose it to our Windows machines, in the form of three shares.
> Sometimes (it's inconsistent but seems to happen several times a week),
> one of our computers will stop 'seeing' the contents of the
> subdirectories of the root of one of the shares.  When we open the
> share in Explorer, the contents of the root appears as expected, but
> when we navigate into any subdirectory it appears as empty.  Meanwhile,
> we can open the share on another machine, and all the subdirectory
> contents appear as expected.
> 
> We've observed this problem on one (and only one) of the shares, which
> is itself confusing as they're all configured exactly the same. 
We've
> tried rebooting the Windows machine but the same problem is observed
> when it comes back.  We've also tried rebooting the Samba service, but
> again the same problem is observed!  If we leave it for long enough,
> however, eventually it starts working again.  Our best guess is that
> the Windows machine somehow caches some bad data, somehow.
> 
> Thus far this problem has only been observed from two of our Windows
> machines; one runs 32-bit Windows XP Pro and the other 64-bit Windows
> Server 2003.
> 
> The Samba log shows everything appearing normal, e.g.:
> 
> [2007/06/18 14:07:12, 2] auth/auth.c:check_ntlm_password(309)
>   check_ntlm_password:  authentication for user [fred] -> [fred] -> 
> fred] succeeded
> [2007/06/18 14:07:12, 2] lib/access.c:check_access(323)
>   Allowed connection from  (192.168.1.149)
> [2007/06/18 14:07:12, 1] smbd/service.c:make_connection_snum(950)
>   kronos (192.168.1.149) connect to service CVS initially as user fred 
> (uid=1000, gid=100) (pid 18524)
> [2007/06/18 14:07:12, 2] smbd/reply.c:reply_tcon_and_X(711)
>   Serving CVS as a Dfs root
I don't suppose you could try 3.0.25 could you ? I re-wrote most
of the DFS code for this release - and this type of thing definately
sounds like a DFS bug.

Jeremy.