Restarting Windows machine stops Linux machine mounting/connecting
 

I am having a great deal of trouble getting a Linux machine to mount folders on a remote networked Windows XP machine reliably. I have four computers at home:

Study (XP Pro);
Bedroom (Ubuntu Hardy);
Parlour (XP Home); and
Kitchen (Ubuntu Hardy).

Study shares two volumes (separate physical drives) over SMB: Blue and Documents. Parlour shares one volume over SMB: Green. Bedroom shares two volumes over both SMB and NFS: /backup and /home/james. Kitchen shares one volume over NFS: /mnt/Red (it also shares the /home/valerie and /home/robert subsets thereof).

All four computers are connected to each other, and to the internet, through a wired network (Cat 5, fast ethernet), using a Westell four-port ADSL router.

There are three user accounts: valerie, robert and james (the Windows equivalents have mixed case usernames, appropriately dealt with in the Samba configuration files). No one computer is a domain server: it is a peer to peer network. On Study, the following network drives are mounted:

G:\ Backup
K:\ Green

On Parlour, the following network drives are mounted:

F:\ Documents
G:\ Blue
H:\ Backup

On Bedroom, the following network drives are mounted:

/mnt/Red
/mnt/Green
/mnt/Blue
/mnt/Documents
/home/robert - mounted from /home/robert on Kitchen
/home/valerie - mounted from /home/valerie on Kitchen

There is also a symlink to /mnt/Documents in /home/james.

On Kitchen, the following network drives are mounted:

/mnt/Green
/mnt/Blue
/mnt/Documents
/backup
/home/james - mounted from /home/james on Bedroom

There is also a symlink to /mnt/Green/[user's documents directory in Windows] in /home/[user] for both robert and valerie.

I first set up the system when both Linux machines were running Feisty. On upgrading to Gusty, however, every time that Parlour was restarted, the mounting of /mnt/Green from Parlour was disrupted: the existing mount would not work, and running either sudo mount -a or sudo umount /mnt/Green would cause the terminal to hang, and only become responsive with CTRL+SHIFT+C. Attempting to enter /mnt/Green would have the same effect. Sometimes, by restarting all four computers several times, the connexion was able to be restored again, but would fail in the same way when Parlour was next restarted. What particular sequence of restarts worked and did not proved idiosyncratic and unpredictable.

I upgraded to Hardy last week-end, hoping that it would solve the problem, but it did not. The behaviour is unchanged. On first upgrading to Hardy, the mounting/connexions worked fine, but, when I next restarted Parlour, the connexions failed again.

As before, it also disrupted the mounting from Bedroom to Study, even when Study had not been restarted (I think), but that was readily fixable simply by remounting from the command line. Checking now (from Study), I cannot see Parlour in the "My Network Places" tab, and cannot access G:\, although all the other three machines appear. Parlour can mount Backup without any difficulty.

Kitchen can mount /backup, /mnt/Blue and /mnt/Documents without difficulty, although cannot ping any other machine on the network (this may be related to firewalls, however: I have Zone Alarm Pro installed on the Windows machines, and Firstsarter on the Linux machines). All four computers can use without difficulty an XMPP IM server located on Bedroom at all times when Bedroom is functioning correctly (although, whenever Bedroom is restarted, the clients cannot connect unless Pidgin is closed and re-opened if it was running before). From Study, pinging bedroom results in successful pings, pinging kitchen results in 100% timeouts, and pinging parlour results in "Ping request could not find host parlour". All four computers can always access the internet without difficulty.

Can anyone help me to untangle this network weirdness and get Kitchen's mounts working again?

For starters, your XP Pro machines are probably blocking Ping probes, as SP2 enables the firewall and it is configured to block ping requests, you can enable that in the Windoze firewall configuration. (Third tab, ICMP, top selection box "Allow ICMP ping requests", and allow the return packets.)

Its possible you may need to enable anonymous IPC connections for the linux box to connect properly, another SP2 change. (secpol.msc -> Local Policies -> Security Options -> "Network Access: Allow anonymous SID/Name Translation" Set to "Enabled" ,if need be, set the shares that can be accessed anonymously here as well, this should probably be a last resort, troubleshooting step, but its helped me in the past)

Some troubleshooting advice for Linux SMB clients: http://myy.helia.fi/~karte/linux_as_...mb_shares.html

Some "dirty" advice:
If you duplicate the entry in the fstab, ie. put it in more than once, like:

//server/share /mnt/smb smbfs credentials=/etc/smbcred 0 0
//server/share /mnt/smb smbfs credentials=/etc/smbcred 0 0
//server/share /mnt/smb smbfs credentials=/etc/smbcred 0 0

It seems as though the first attempt "wakes up" smbfs so that a subsequent remount attempt then works. I know that's dirty as hell, but it works.

Or, to add a delay to the mount:

From /etc/init.d/smbfs

case "$1" in
start)
echo -n >&1 "To prevent Connection Failed error messages wait 60 seconds until the network is available."
sleep 60
grep -q '^[[:space:]]*[^#].*[[:space:]]\(smbfs\|cifs\)[[:space:]]' /etc/fstab
rc=$?

Thats out of the way..

Have you considered switching from SMB to CIFS ?

From linux-cifs.samba.org

The CIFS VFS provides some support for older servers based on the more primitive SMB (Server Message Block) protocol (you also can use the Linux file system smbfs as an alternative for accessing these). CIFS VFS is designed to take advantage of advanced network file system features such as locking, Unicode (advanced internationalization), hardlinks, dfs (hierarchical, replicated name space), distributed caching and uses native TCP names (rather than RFC1001, Netbios names). Unlike some other network file systems all key network function including authentication is provided in kernel.

Its like SMB, but better!

Grizly,

thank you very much for your help :-) It is much appreciated.

I do not use Windows Firewall - it is manually disabled. I use Zone Alarm Pro instead. I have just checked, and Zone Alarm Pro is configured for "medium security" for the trusted zone (all the IP addresses of my network: each machine has a fixed internet IP address; no NAT is used), which is configured to allow pings.

Will this adversely impact security? I find it a little odd, though, that the problem would be with one machine and not another if this was the solution.

Thank you for that - I shall have to take a look. However, I have something of a suspicion that this is not so much a Samba-specific problem as a network problem because of the inconsistent pings.

Ahh, that is interesting. I am wondering, though, whether it will work for me, when repeated manual attempts at re-mounting produce no success, and where the mounted connexion is broken whenever the XP machine is restarted.

I already use CIFS :-)

Thank you again very much for your help.

Yes.. it would adversely affect security.. (hence the "last resort, troubleshooting step" phrase.. so, I probably shouldn't have mentioned it at all)


It could be that when you reboot, the NetworkManager (whatever app is doing it in your case) is reconfiguring the network, but after it has tried to mount the shares.

You could check the order of the startup scripts to determine which is happening in which order, and modify them so they do things more sanely.. (like get the network working before you ask for a DHCP address etc.. believe me, I've seen it) Ensure that SMB, NMD and winbind are all started after the network.

If you are running a DNS server, you should check that to resolve your name resolution issue, but if not, then you may be relying on WINS.. (or the NMD part of samba)
In which case, you should verify your hosts files on each machine.

linux hosts file: /etc/hosts
windows hosts: c:\windows\system32\drivers\etc\hosts

And check the order they are resolved in. (windows defaults to hosts) Linux should too.

If you are dropping packets.. it could be an issue with something lower in the stack..like drivers or cables.. how are they physically connected?