Bug 235821 - Windows XP cannot connect to Samba-3.0.24-4.fc5
Summary: Windows XP cannot connect to Samba-3.0.24-4.fc5
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: samba
Version: 5
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Samba Maint Team
QA Contact: David Lawrence
URL:
Whiteboard:
: 235846 235890 235970 236215 236610 237915 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-04-10 11:54 UTC by Tomasz Ostrowski
Modified: 2007-11-30 22:12 UTC (History)
9 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-04-10 14:57:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Samba Project 4502 0 None None None Never

Description Tomasz Ostrowski 2007-04-10 11:54:52 UTC
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.

Comment 1 Yanko Kaneti 2007-04-10 12:26:23 UTC
Same here.

Comment 2 Yanko Kaneti 2007-04-10 13:26:02 UTC
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 ?

Comment 3 Tomasz Ostrowski 2007-04-10 14:38:36 UTC
I've compiled samba-3.0.24-4 without samba-3.0.24-msdfs-root-no.patch and it
started to work.

Comment 4 Simo Sorce 2007-04-10 14:57:32 UTC
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 :/

Comment 5 Simo Sorce 2007-04-10 15:01:05 UTC
*** Bug 235846 has been marked as a duplicate of this bug. ***

Comment 6 Simo Sorce 2007-04-10 16:10:20 UTC
(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?



Comment 7 Yanko Kaneti 2007-04-10 17:08:59 UTC
(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

Comment 8 Jan Kratochvil 2007-04-10 17:17:29 UTC
(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.


Comment 9 Simo Sorce 2007-04-10 17:28:31 UTC
> 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.



Comment 10 Simo Sorce 2007-04-10 17:42:42 UTC
*** Bug 235890 has been marked as a duplicate of this bug. ***

Comment 11 Yanko Kaneti 2007-04-10 17:55:28 UTC
(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.

Comment 12 Tomasz Ostrowski 2007-04-11 07:55:54 UTC
(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.

Comment 13 Simo Sorce 2007-04-11 13:13:38 UTC
*** Bug 235970 has been marked as a duplicate of this bug. ***

Comment 14 Simo Sorce 2007-04-12 20:47:52 UTC
*** Bug 236215 has been marked as a duplicate of this bug. ***

Comment 15 Ben Lentz 2007-04-13 17:59:15 UTC
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!

Comment 16 Simo Sorce 2007-04-13 18:53:12 UTC
(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.


Comment 17 Simo Sorce 2007-04-16 21:12:52 UTC
*** Bug 236610 has been marked as a duplicate of this bug. ***

Comment 18 Simo Sorce 2007-04-27 15:19:03 UTC
*** Bug 237915 has been marked as a duplicate of this bug. ***


Note You need to log in before you can comment on or make changes to this bug.