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.
Christian Perrier wrote:
I do realize that there does not appear to be any failures in the log
files. I turned logging up to 10 and then trolled through it and still
didn't find anything that I thought was suspicious or unusual.
The failure is that the share can not be accessed in any way
(apparently), though it is listed as a valid share on the serving host.
I can't browse it from a Windows XP system, and a remote SMB mount
from another Linux host fails as soon as I upgrade -- while other shares
continue to work just fine.
What is the message on the client side ?
What happens if you try connecting the share from the server itself
with smbclient: smbclient -U shara //localhost/share ?
There *should* be something in the logs, if something wrong happens
--
# Jesse Molina
# Mail = [EMAIL PROTECTED]
# Page = [EMAIL PROTECTED]
# Cell = 1.602.323.7608
# Web = http://www.opendreams.net/jesse/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
