[Pkg-samba-maint] Bug#429767: samba: A Samba share named "share" is quietly invalid.

[Jesse Molina]

I agree -- that does look like my problem.

My initial reaction to reading it is "I'm not using DFS, so I'm not 
affected!"

What the release notes seem to be saying though, is that DFS support was 
previously enabled by default and now it's being turned off.

Oh well, that's life on unstable.

Thanks for following the wild goose chase!



Christian Perrier wrote:
> Quoting Jesse Molina (jesse at opendreams.net):
>> This bug is squirrelly enough that I'm not terribly interested in following 
>> it any longer.  Let's just close this and forget it ever happened.  There 
>> is a simple workaround anyway.  =)
>>
>> I can still reliably reproduce this error, but with some added constraints 
>> and information, which make my original bug report misleading.
>>
>> First, I no longer believe that this is a problem with the name of the 
>> share -- the share could be named anything.  I just happen to be having a 
>> problem with my "share" share because it is the most often used share.  I 
>> am also able to produce this problem with other shares.
>>
>> On my Linux system that was mounting the share, simply forcing an unmount 
>> and remounting the share will resolve the problem.  However, until this is 
>> done, the mount will not be accessible.  Beyond this, I didn't test the 
>> behavior of my Linux client.  I use NFS on my other systems anyway.
>>
>> On my small group of Windows XP systems, I found that simply rebooting the 
>> client host will resolve this problem.  It almost seems as though this is a 
>> caching issue on the client side, but I've never before had this problem 
>> during Samba upgrades.
>>
>> It is also notable that the Windows XP systems must have an uptime of 24 
>> hours or so.  A freshly rebooted system won't have this problem at all.  I 
>> verified this twice on two different systems.
>>
>> This won't effect drive-letter mappings, but it will effect oft-used UNC 
>> shares, such as \\myhost\myshare.  Additionally, if \\myhost\share becomes 
>> inaccessible after the upgrade, accessing the share via a CNAME or fully 
>> qualified name, such as \\myhost.foo.bar\myshare will work just fine.
>>
>> The error message received from a Windos XP system is, "\\host\share refers 
>> to a location that is unavailable.  It could be on a hard drive on this 
>> computer, or on a network.  Check to make sure that the disk is properly 
>> inserted, or that you are connected to the Internet of your network, and 
>> then try again.  If it still cannot be located, the information might have 
>> been moved to a difference location."
>>
>> Rebooting the Windows systems fixes the problem.  Flusing the local DNS and 
>> NetBios (ipconfig /flushdns and nbtstat -R) cache won't fix the problem.  I 
>> didn't try restarting the browser service.
>>
>> Using smbclient on the Samba server locally works just fine, both before 
>> and after the upgrade.
> 
> Well, with this information, I suggest you read this from the release
> notes:
> 
> Changes to MS-DFS Root Share Behavior
> =====================================
> 
> Please be aware that the initial value for the "msdfs root" share
> parameter was changed in the 3.0.25 release series and that this
> option is now disabled by default.  Windows clients frequently require
> a reboot in order to clear any cached information about MS-DFS
> root shares on a server and you may experience failures accessing
> file services on Samba 3.0.25 servers until the client reboot
> is performed.  Alternately, you may explicitly re-enable the
> parameter in smb.conf.   Please refer to the smb.conf(5) man page
> for more details.
> 
> 

-- 
# Jesse Molina
# Mail = jesse at opendreams.net
# Page = page-jesse at opendreams.net
# Cell = 1.602.323.7608
# Web  = http://www.opendreams.net/jesse/