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.
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 :-)
You can email your log file (gzipped) to me (<email@example.com>)
A similar bug was reported in Debian:
(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.
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.
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
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"...
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.
Reading carefully WHATSNEW.txt again I saw this:
Changes since 3.0.24
o Volker Lendecke <firstname.lastname@example.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.
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.
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.
(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"
*** Bug 4617 has been marked as a duplicate of this bug. ***