Red Hat Bugzilla – Bug 235821
Windows XP cannot connect to Samba-3.0.24-4.fc5
Last modified: 2007-11-30 17:12:01 EST
Description of problem: Windows XP cannot connect to Samba-3.0.24-4.fc5 server. Version-Release number of selected component (if applicable): samba-3.0.24-4.fc5 Up-to-date Fedora Core 5 Up-to-date Windows XP Professional Service Pack 2 (Polish version) How reproducible: Always Steps to Reproduce: 1. explorer \\server\share on Windows XP Actual results: (This is my poor translation of an error message from Polish version of Windows XP - actual message would use different wording): \\server\share references location that is unavailable. It can be present on this computer hard drive or on the network. Make sure that a drive is proprely installed and that you have internet connection and try again. If man still cannot locate information, perhaps it was moved to another location. Expected results: A window with share shows. Additional info: 1. Downgrading to samba-3.0.24-3.fc5 helps. 2. I've tried with minimal smb.conf [global] security = share [tmp] path = /tmp public = yes and with selinux disabled and it didn't work. 3. The problem does not show up when using smbclient to access share.
Same here.
Forgot to mention. Here its a Windows XP Proffesional SP2 (English) fully up to date against fc6 samba. The error is basically the same. I just glanced the changset between 3.0.24-3 and 3.0.24-4 and the amount of change there is unacceptable for an update of a stable distribution. There are directory structure changes!? Its no wonder things break. It begs the question if this update has been tested at all ?
I've compiled samba-3.0.24-4 without samba-3.0.24-msdfs-root-no.patch and it started to work.
ok the problem you have is that windows clients need a reboot when you change that option :( Unfortunately enabling it by default in 3.0.24 was a mistake, and 3.0.25 is back to disabled by default again. Can you try to put back 3.0.24-4 original and just reboot your windows client? Closing this bug as this is really a Windows client bug not a samba bug :/
*** Bug 235846 has been marked as a duplicate of this bug. ***
(In reply to comment #2) > I just glanced the changset between 3.0.24-3 and 3.0.24-4 and the amount of > change there is unacceptable for an update of a stable distribution. There are > directory structure changes!? Its no wonder things break. It begs the question > if this update has been tested at all ? I don't recall any major directory structure changes in FC6, and all the poatches added are bug fixes, _required_ to make samba 3.0.24 work with Vista. The changes have been tested and this problem was expected. I decided to change the default anyway because the old default break more things in more subtle ways. Can you be a bit more positive in the future? I am trying to fix bugs and you complain? Maybe then you would complain if bugs were not fixed timely as well?
(In reply to comment #6) > (In reply to comment #2) > > I just glanced the changset between 3.0.24-3 and 3.0.24-4 and the amount of > > change there is unacceptable for an update of a stable distribution. There are > > directory structure changes!? Its no wonder things break. It begs the question > > if this update has been tested at all ? > > I don't recall any major directory structure changes in FC6 I mean the fhs compliance set, changing directory layout especially under /var is something to be avoided in a stable series > and all the poatches added are bug fixes, _required_ to make samba 3.0.24 work with Vista. This wasn't communicated clearly, if at all in your update announcement or in some other fedora place. > The changes have been tested and this problem was expected. I decided to change > the default anyway because the old default break more things in more subtle ways. > Can you be a bit more positive in the future? I am trying to fix bugs and you > complain? So to spare us both from further such episodes, my I ask you to consider twice when making such changes in the future, and making sure that people know about them beforehand. Preferably by big bold letters in the update announcement. TIA
(In reply to comment #6) > The changes have been tested and this problem was expected. I decided to > change the default anyway because the old default break more things in more > subtle ways. As the server is aware of its shares list I believe it could try to find if there is a unique share with name "sharename?" (with arbitrary one added letter) to keep there the compatibility - printing a warning to its logs; no matter whose bug was the cause. On the other hand such level of brokeness backward compatibility may be the RHEL differentiation factor.
> I mean the fhs compliance set, changing directory layout especially under /var > is something to be avoided in a stable series I don't know what are you talking about. I made changes in /var only for FC7 packages, nothing has been touched in FC6 pacakges! > > and all the poatches added are bug fixes, _required_ to make samba 3.0.24 work > with Vista. > > This wasn't communicated clearly, if at all in your update announcement or in > some other fedora place. I will try to put up a better announcement next time, but I added only bugfixes no other change worth of notice. > So to spare us both from further such episodes, my I ask you to consider twice > when making such changes in the future, and making sure that people know about > them beforehand. Preferably by big bold letters in the update announcement. I am sorry this problem bit you, but this is no reason to get so upset. The problem is easy fixable (a clien reboot, or a change in smb.conf) even if surprising. I will try to document such changes better in the future.
*** Bug 235890 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > > I mean the fhs compliance set, changing directory layout especially under /var > > is something to be avoided in a stable series > > I don't know what are you talking about. > I made changes in /var only for FC7 packages, nothing has been touched in FC6 > pacakges! My mistake. I saw the patch appear in the FC-5/6 commit logs and automatically assumed it was applied there. Please accept my apologies.
(In reply to comment #4) > ok the problem you have is that windows clients need a reboot when you change > that option :( It is not enough to reboot a client computer as this bug it would not show up in my network - a server was updated at night when client computers were off. Samba shares are mounted as drives in my network so to make things work I'd have to unmount a drive, reboot and then mount a drive again. As it requires a reboot in the middle it is very hard to do by scripting. And it would be required for every user in the network which is using mounted samba shares (only 2, but it could easily be hundreds). So, as a workaround I'd recommend everyone adding: msdfs root = yes to a [global] section of /etc/samba/smb.conf. This would force a problematic setting to old default value. And this problematic patch at least should change a smb.conf man page as it now says, that "msdfs root" is "yes" by default and it is not.
*** Bug 235970 has been marked as a duplicate of this bug. ***
*** Bug 236215 has been marked as a duplicate of this bug. ***
FWIW, I encountered this issue earlier this week on a production FC5 server when yum updated this package overnight and things started breaking. The [global] msdfs root = yes workaround works great. "Reboot" would be a viable solution if this were 10 years ago and I was running Windows 95. On the other hand if I really cared, I shouldn't have my production servers updating automagically without thorough QA... but I normally have a huge amount trust in you guys to do that for me!
(In reply to comment #15) > FWIW, I encountered this issue earlier this week on a production FC5 server when > yum updated this package overnight and things started breaking. The [global] > msdfs root = yes workaround works great. > > "Reboot" would be a viable solution if this were 10 years ago and I was running > Windows 95. On the other hand if I really cared, I shouldn't have my production > servers updating automagically without thorough QA... but I normally have a huge > amount trust in you guys to do that for me! It was not an easy decision to take, but the old default "msdfs root = yes" has other subtle problems that are much moe difficult to diagnose. We had to change this back to pre 3.0.24 defaults (upstream is going to do the same in 3.0.25). Sorry for the issues, but it was, unfortunately a 1-0 decision.
*** Bug 236610 has been marked as a duplicate of this bug. ***
*** Bug 237915 has been marked as a duplicate of this bug. ***