Bug 4619 - Shares stop working with 3.0.25
Shares stop working with 3.0.25
Status: CLOSED WORKSFORME
Product: Samba 3.0
Classification: Unclassified
Component: Upgrade
3.0.25
x86 Linux
: P3 major
: 3.0.25
Assigned To: Gerald (Jerry) Carter
Samba QA Contact
:
: 4617 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-15 07:57 UTC by Florian Effenberger
Modified: 2007-05-22 07:16 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Effenberger 2007-05-15 07:57:17 UTC
I hope qualifying this issue as "major" is allright. I already read some other occurences of this problem on the list.

Samba 3.0.25 (3.0.24 with security patches is unaffected) stops working on some shares, at least when being accessed from Windows XP. Attached is a log file. The Windows client tells me the path is unavailable. Going back to 3.0.24 solves that problem.
Comment 1 Florian Effenberger 2007-05-15 08:09:29 UTC
Can I e-mail the log file to someone? It may contain sensitive data, so I don't want to publish it on the net :-)
Comment 2 Gerald (Jerry) Carter 2007-05-15 08:10:10 UTC
You can email your log file (gzipped) to me (<jerry@samba.org>)
Comment 3 Christian Perrier 2007-05-17 10:05:12 UTC
A similar bug was reported in Debian:
http://bugs.debian.org/424610
Comment 4 imacat 2007-05-17 10:20:32 UTC
(In reply to comment #0)
> I hope qualifying this issue as "major" is allright. I already read some other
> occurences of this problem on the list.
> 
> Samba 3.0.25 (3.0.24 with security patches is unaffected) stops working on some
> shares, at least when being accessed from Windows XP. Attached is a log file.
> The Windows client tells me the path is unavailable. Going back to 3.0.24
> solves that problem.

    I encounter similar issues.  After isolating the possible causes one by one (client hosts, user, etc.) I found that it is specific to "some" drive-letter mapped shares.  For these shares if I disconnect the drive-mapping and re-map it from the network neighborhood, everything goes fine now.  It looks like some client drive-mapping cache was altered.  But this is merely my guess.  I did not read the source.  The log file shows nothing, too.

    Hope this helps.
Comment 5 Florian Effenberger 2007-05-18 05:27:45 UTC
I got the tip that setting

msdfs root = yes

cures the problem, and it seems to. In 3.0.24, msdfs root was yes by default. Don't know if it really solves and if it has side effects.
Comment 6 Gerald (Jerry) Carter 2007-05-18 07:41:45 UTC
The change in the default setting for "msdfs root" was describe 
in the release notes.  Perhaps we should have added a stringer 
mention that clients cache this setting for a given server.
In either case, there is no bug in Samba.  Simple confusing 
client behavior.
Comment 7 Florian Effenberger 2007-05-18 17:12:07 UTC
Okay, now it seems to work. However, I think switching the default behaviour is risky, as a lot of people will walk into this "bug"...
Comment 8 Gerald (Jerry) Carter 2007-05-18 21:32:56 UTC
The parameter default change for "msdfs root" is the least of my 
worries in 3.0.25.  Change sin the minor number indicate an 
upgrade release, not a patch release.  This was clearly stated 
in the release notes.  

We will continue to be very agressive in the upgrade releases
and continue to stablize using the bug fix (or letter) releases.
it's not perfect, but seems to work as well as any other method.
Comment 9 imacat 2007-05-20 04:59:28 UTC
    Reading carefully WHATSNEW.txt again I saw this:

========================
Changes since 3.0.24
--------------------
commits
-------
...
o   Volker Lendecke <vl@samba.org>
...
    * Revert "msdfs root" to default to "no".
...
========================

    Well, this is *really* helpful.  I read the WHATSNEW.txt line by line before upgrade.  But still, for some functionality I do not understand and am not using, by simply reading that line I cannot possibly know that it will cause so serious trouble, cost me a whole day and almost got fired.  Maybe you can note this in the [Major Changes] or [Notes Before Upgrade] section.

    Besides, I do not see this in 3.0.25 "smb.conf changes" list.  Someone failed to list it.

    After some reading on MS DFS, I agree that basically this decision is right.  Setting "msdfs root" defaults to "no" should be a correct and secure decision for people that are not aware of MS DFS.  I do not agree the quick solution by adding "msdfs root = yes".  However, the documentation of such important change can still be a lot better.
Comment 10 Patrick Rynhart 2007-05-22 01:54:33 UTC
https://bugzilla.samba.org/show_bug.cgi?id=4617 also describes this "bug". The release notes don't state that clients/member servers require a reboot with this "msdfs root" change.
Comment 11 Gerald (Jerry) Carter 2007-05-22 07:15:04 UTC
cmoe on folks.  Give me a break.  I've not added it to the 
release release notes for 3.0.25a.  Everyone has made their 
point.  I will not continue to discuss this over and over.
Comment 12 Gerald (Jerry) Carter 2007-05-22 07:15:47 UTC
(In reply to comment #11)
> cmoe on folks.  Give me a break.  I've not added it to the 
> release release notes for 3.0.25a.  

Should say "now added it to the release notes for 3.0.25a"
Comment 13 Gerald (Jerry) Carter 2007-05-22 07:16:40 UTC
*** Bug 4617 has been marked as a duplicate of this bug. ***