[Samba] BINGO - bug - 3.0.14, 3.0.21 intractable browsing problems

[Stephen Bosch]

Jeremy Allison wrote:
> On Mon, Jan 30, 2006 at 08:08:52PM -0700, Stephen Bosch wrote:
> 
>>Okay, folks -- we've found the cause of the problem.
>>
>>To recap: With our Samba server as the master browser, the domain window
>>in My Network Places is totally empty, irrespective of what client we
>>use (Windows 98, 2000, XP).
>>
>>When Samba is not the master browser (i.e., another workstation is
>>acting as the master browser), hosts are visible.
>>
>>When Samba is the master browser, the browse.dat and wins.dat files are
>>populated correctly with the hosts on the network.
>>
>>Our browse.dat and wins.dat files are stored in /var/cache/samba.
>>
>>The directory had permissions of 744. With the permission set as 744, no
>>worky. With the permissions set at 755, tada -- suddenly it works. A
>>whole host of problems are resolved. A permissions problem (what we
>>initially suspected) but not one that was simple to devine. The browse
>>connections are made by an unprivileged user, and with permissions of
>>744, that user cannot enter the directory, even if the files are readable.
>>
>>This is the sort of problem that a perusal of the nmbd log should have
>>made immediately obvious. If Samba can't read a vital file, shouldn't it
>>be reporting that in the logs? We've reproduced the problem with the log
>>level set at 9; though nmbd reports that the browse.dat file is being
>>written to, it never says anything about being unable to read it or
>>unable to enter the cache directory. If it had, we would have taken
>>three minutes to fix this problem instead of three weeks.
>>
>>We didn't see an error to this effect in the session logs, either.
>>
>>Perhaps there's something misconfigured with our logging -- but it seems
>>just as likely that Samba isn't reporting a failure to read the
>>browse.dat and wins.dat files to the logs.
> 
> 
> Hmmm, here's the failed to read wins.dat file message :
> 
>         if((fp = x_fopen(lock_path(WINS_LIST),O_RDONLY,0)) == NULL) {
>                 DEBUG(2,("initialise_wins: Can't open wins database file %s. Error was %s\n",
>                         WINS_LIST, strerror(errno) ));
>                 return True;
>         }
> 
> That should probably be a debug level 0 - I'll fix that in
> the code for 3.0.22.

I guess it depends on whether nmbd is accessing wins.dat as root or not.

> Here's the browse.dat message from smbd:
> 
>   lines = file_lines_load(lock_path(SERVER_LIST), NULL);
>   if (!lines) {
>     DEBUG(4,("Can't open %s - %s\n",lock_path(SERVER_LIST),strerror(errno)));
>     return(0);
>   }
> 
> Ouch ! Level 4..... This may have been your underlying problem. nmbd
> may have been able to write this but smbd may not have been able
> to read it given the connected user.

Well, this is our own fault -- we never checked the smbd logs because we
thought that, being a browsing problem, this would be handled strictly
by nmbd -- but then I suppose that the browse list has to be transferred
to the requesting client somehow.

We would have caught this at debug level 9. We grepped the logs for
"browse.dat", but we were only checking the nmbd log.

> but from nmbd :
> 
>         fp = x_fopen(fnamenew,O_WRONLY|O_CREAT|O_TRUNC, 0644);
> 
>         if (!fp) {
>                 DEBUG(0,("write_browse_list: Can't open file %s. Error was %s\n",
>                         fnamenew,strerror(errno)));
>                 return;
>         }
> 
> So you should have seen a meesage from nmbd - it's logging at a
> debug level 0.

Well, it wasn't having any trouble writing the browse list. That's why
this evaded detection for so long. As you say above, it was writing the
browse list, it was putting current information in the browse list, and
it was reporting the browse list contents when queried by a local
client... running as root. I can only presume that Samba also writes to
the browse.dat file as root.

The problem only appears -- with the permissions as they were (744) --
when an unprivileged user (the guest account) *asks* for the browse
list. I'm still pretty sure this failure is silent, but I'll try it
again while watching the logs, now that I can consistently reproduce the
problem.

If I may make a suggestion, it would be useful, too, if Samba would
return an error to the client so that it throws up an error dialog. This
would have helped us rule out client-side problems, the pursuit of which
ate up a lot of time.

I can tell you, however: I am SO relieved we traced this problem. I hope
our pain will be somebody else's gain, so perhaps we could

- change the logging characteristics
- have Samba return an error to the client
- add a note describing this gotcha to the "Domain Browsing" section of
the Samba How-to, which will make it even more excellent than it already
is :)

I'm kinda surprised this kind of thing hasn't happened before, or if it
has, that all my searching didn't uncover any posts to the list...

-Stephen-