Hi.

This one is driving me nuts. I hope that someone might have some insight that will make me sleep easier, before I take a hammer to the machine

OK. Here's the scenario. I have a moderately complex home network, running gigabit ethernet between several servers and a mix of desktop and laptop machines with different OSs on. There are three linux boxes running three different versions of linux with three different versions of samba. All are configured in essentially the same way but with different shares and different purposes, thse being a media server, a data server, and a mail server.

There is also the tape server, which is normally off, only on when it's needed, with a large LTO3 tape robot connected to it.

Everything is connected to the cable router and each other via three 8 port gigabit switches. Recently, as in about two weeks ago, everything was taken apart and rebuilt when I moved my office from one room to another, so now more or less everything is in one room. It worked fine there until two days ago. Then it went odd.

Everything except for the windows 7 box is still running perfectly happily. All the various laptop and desktop machines can see each other and the servers, can mount samba shares, copy files around, do all the things you'd want. The damn 7 box, though, two days ago suddenly decided not to work right with the data and mail servers.

It will see a share, connect to it, let you list a directory, copy files to it and from it, create and delete directories, all the normal things. But it will NOT allow you to open a file in place. IE, if you double click a text file on the server it doesn't work. You can copy it to the windows 7 box then open it, that works. Doesn't matter what the file type is it doesn't work.

The way it fails is that you get a slow green progress bar crawling across every file explorer window open on a network share a few seconds after you try to access the file, regardless of whether that window had the file in. Nothing else happens, and at that point you can't use the network browser at all. This process will apparently never end, I've left it running for a couple of hours with no luck.

If you do ipconfig /release in a command window the program that should have started instantly starts, then complains about the lack of network connectivity and can't load the file, which is fair enough. Renewing the lease will allow the network to work again, except that this behaviour will repeat.

I've googled it, tried everything I can think of from both hardware and software, with no luck. So far I have:

Completely rearranged the network, tried different switches, cables, topology, etc.

Uninstalled and reinstalled samba on the two affected servers, fiddled with smb.conf for hours, tested them in every way I can think of.

Uninstalled anything that might have been installed on the machine in the last week.

Uninstalled and reinstalled the ethernet drivers on the windows box on the off chance it would help.

Tried altering a number of settings in windows I found during my search.

Removed as much as possible from the network, leaving only the router, the windows box, and the data server connected.

And many other little tweaks. Nothing has had any effect one way or the other. Except for this behaviour the machine works fine, web browsing, email, video playback from the media server, all that works correctly.

The two XP machines and the linux laptop I tried all work with all three servers perfectly, as they always have done. The network and the servers are, I'm 99% sure, not the problem.

Ideas?

Clearly the thing is waiting for something to happen, but as usual there is no feedback at all to tell me what or why. It just stops. Three days ago it worked perfectly, as it has done for over a year. I did a windows update about eight or nine days ago but it's been rebooted numerous times between then and when it went weird. Twice today, just to add insult to injury, it went through a brief period of working right for about a minute, once on each server but at different times. It then immediately died again and I have no idea what, if anything, I did to make it work. I'm stumped. And annoyed.

pca

Have you tried a different NIC on the Windows 7 box?

I concur with Dignan.
I recently also experienced weird network problems, and, after much fiddling with it, could track the issue down to the driver of the network card. In my case, it's a real Intel onboard network chip, but I let it use the Windows driver that got installed when the OS was. Everything worked then, but network speed did not come above 9 MB/s and sometimes locked up too, even though the system insisted the connection was a Gigabit connection. As a last resort kind of thing, I eventually installed the real Intel NIC card drivers and that magically worked!

Maybe that Windows update did something with the NIC card driver? It's worth checking out.

I'll dig one out and try it, if I can. The machine has no free slots so I'll have to remove another card.

I don't think it's that, though. I did delete the original drivers completely then reinstall from new ones from the motherboard manufacturer, and in all other respects the networking runs correctly. I can write to the data fileserver at 60 MB/s, for example, so speed isn't the problem. It's just opening a file that's on it that is the issue.

pca

USB2/USB3 GigE NICs are useful for sorting out issues like this. No need to crack open the box and free up a slot.

Yeah, I'd be surprised if it was the issue too, but it was the only thing I could think of

I understand your frustration, though. My least favorite thing in troubleshooting computers is when things kind of work. It's much easier when they don't work at all.

A further piece of data. If I map one of the shares on one of the servers to a drive, it works perfectly. The raw share on the same machine does not.

It must be some weird sort of name lookup thing, but I'm puzzled as to what it is, why it suddenly happened, how to fix it, and why it never times out or give me any feedback as to what's happening.

pca

That's kind of odd. What happens if you use an ip_address in the raw share, rather than the hostname?

Exactly the same thing as with the name.

pca

Antivirus gone bananas? (Is it just double-click that goes wrong, i.e. can you open files from File->Open dialogs?) Just trying to think of something that's in the ShellExecute path but not the file copy path. Is there anything busy in Task Manager during a fail event?

Peter

That would seem to rule out name lookup, then.

What do the samba.conf files look like on the "broken" servers? What's the difference between those and the working server?

What are the permissions on the files?

IIRC, access via mapped drive and unc path use different authentication schemes. Is it possible that it's the authentication step that's failing? Are the samba hosts passing authentication back to one of the Windows machines, and have an outdated Kerberos ticket? Have the IP addresses of any of your machines changed, or are they statically assigned?

Though, since you can see the server content, just not open it, the above seems like it's not the solution. I don't know how fine-grained the UAC on Windows are. Maybe it's only getting hung up on "open-for-write"?

I tried uninstalling any antivirus programs, and anything else installed in the last two weeks. No difference.

Any access to the raw share fails in the same way, regardless of method. Double-clicking on a text file kills it in the same way as file-open from wordpad does, for instance.If I map a drive letter to it everything works. But that would give me quite a lot of drives, which would have to be remapped when I reboot it.Not really an ideal solution.

pca

I've spent some time rewriting all the smb.conf files to be the same on all the servers except for the name and the shares, based on the one on the working server. It made no difference.

The files have various permissions. The media server shares are read only public ones while the other two servers are user private rw. But, as I say, it all worked fine up to about three days ago.

The servers are all on static IPs. The desktop machines are DHCP.

No idea what the problem is. I've spent hours fiddling with it, nothing I've tried has affected it at all. I've even tried setting up a WINS server, which has had no effect either one way or the other. I really don't want to have to reinstall the entire damn os and hundreds of applications to fix one stupid problem. Especially one that was created from nowhere. That's a week of my time I'd prefer to use for more interesting things

pca

I had this same problem as well as a timeout problem that made it impossible to do backups from W7. I too spent about a week trying to fix it, and finally resolved it by upgrading to XP.

Since "normal" Samba operations are working, this still smells like an issue where the client makes a request of the samba server and the samba server requires additional authentication before it can reply to the client, but times out trying to get that authentication. (But then, I thought that all authentication necessary took place in the session setup.)

For the user-private rw, which machine is controlling authentication? Are the samba servers each set up with identical sets of users (i.e. authentication through users stored in /etc/samba/smbpasswd (or passdb.tdb), created via smbpasswd), or is Samba configured to use winbindd, to look up authentication and UAC details from a Windows machine? And, if the latter, which machine serves up the user details?

Have you tried running wireshark, to see what's happening on the network? On both client and server?

The only other common thread I see, here, is that XP and Linux work, while it's Windows 7 that doesn't work. Maybe it's related to the protocol getting used? The former have no SMB2 support, while the latter can use SMB2 if the server is configured to use it. SMB2 has more security "features" for ACLs, so perhaps they're getting in the way. Are the Samba servers configured to use the SMB2 protocol? And if so, does the problem go away if you turn it off (remove the 'max protocol = SMB2' line)?

Does this problem only happen when you double-click the file in Explorer? Or does it also happen if you open the application first, then do File->Open (or the equivalent)?

Did the Win7 update change any settings in the UAC? What happens if you dial down/turn off the UAC settings?

Well, after trying everything I could think of to fix this problem, with no luck, I eventually gave up. I did try installing a fresh copy of win7 on a spare drive, which worked perfectly, proving beyond doubt there was nothing wrong with either the hardware or the linux server config. Unfortunately that wasn't an option for the box in question as it would have taken days to a couple of weeks to reinstall all the programs and get everything working correctly.

I ended up just mapping drive letters to the relevant shares, which is a usable workaround although clunky. It kept me going all right, though.

Then, about a week ago, I accidentally double-clicked an ODF document on the server share directly, which was the part that had stopped working.

It worked perfectly...

At some point between the last time I checked a couple of months ago, and a week ago, the problem fixed itself as mysteriously as it had broken itself I have no idea what broke, why, how, or when, or the same for why it suddenly started working again. I've tested it thoroughly and it's working as well as it ever did. No idea at all.

Don't you just love the semi-random non-deterministic behaviour of windows?

pca

Makes me wonder if Windows Update is on, and a patch broke something, and then, another patch fixed it...

Patrick, I hope you don't mind if I hijack your thread here, but I'm having a Windows networking issue myself and I'm hoping someone might know what's going on.

I have a client with a Windows Home Server, and I just upgraded her laptop from XP to 7 because of the EOL. After finally working out why the computer was incapable of connecting to the server (turns out the server's clock was set to April 11th 2007), I was able to get to the shared files on it.

The problem is that she has to log into the server every single time she reboots her computer (or, more accurately, when she logs in). I don't think she'd mind, except that her husband gave her a long, annoying-to-type password for her account.

The incredibly frustrating part - the part that makes me pissed at Microsoft for poor design - is that the login dialog has a checkbox for the user to tell the system to save the login information they're entering. But it doesn't! Sure, I guess it saves it until the she logs out and back in again, but that's not what people think the system means by that.

I can see that the login information is being saved to the Windows credentials manager. It has the server name, the username, and seems to store the password in there too. But sure enough, if she reboots her computer the next time she tries to access that server it asks her for her credentials.

Anyone know how to fix this? Additional info: the server is Home Server 2008, the computer is Windows 7 Home. I don't have the network share mapped to a drive, but I think it would do this whether or not I did. There are two other computers in her house connected to the server, one running Vista and the other running 8, and neither one has to log in every time they connect to the same share...

Thanks for any help.

Is putting the user name and password into a batch file that runs NET USE out of the question? You could just run that at startup.

NET USE \\computer\share /U:domain\user /P:password

By the way when you type that by hand, what is the output from it? Does it succeed or give an error, and what is the error if so?

That's a good call. I'll try that the next time I have access to the computer. Thanks!

Update: Thanks, Tony! It's a bit of a kludge, but it mostly works. The only problem is that at the point of login, sometimes the network adapter hasn't connected yet, and the command times out. I've created a shortcut to the batch file on the user's desktop in case of this.

BTW, I had to change the command slightly to the following:

NET USE \\computer\share /U:domain\user password /persistent:yes

Ah, right, I hadn't remembered the parameters correctly.

There may be additional things you can do, to make the batch file wait until the network adapter is connected before trying its trickery. Or perhaps there is a feature in Windows Task Scheduler to fire off the task only when connecting successfully to that specific network.

Strangely, that's what the "/persistent=yes" is supposed to do: Automatically connect under those conditions. Why it's not working on that system... I don't know. So yeah, it's a kludge that works around the fact that a basic level thing on Windows isn't working as you expect.

Indeed! I've come across a few threads with people having the exact same experience, but I never saw any solutions. It has to be a bug of some sort, but I doubt I'll find a solution. The most frustrating part was definitely the fact that the credentials were right there in the system, but for some reason the OS wasn't using them when she tried to connect.

If I'd had unfettered access to the system for a long period of time (both client and server), I would have been investigating the path of why the credentials weren't automatically working. Generally when I see that happen, it's for tricky little reasons. For example, the server could be rejecting the auto-credential login because of a domain or RADIUS problem (doubt they're using a RADIUS server but this is just an example). The client could be sending the wrong domain name to the server as part of the credentials. The client could have two shares open on the same server, and be authenticating automatically (successfully) against the other share with different credentials (windows throws an authentication error when you double-login the same client machine). That's the sort of thing I'd be looking for. But those kinds of things would require a lot of hands-on time with both the client and the server to figure out what's wrong. The batch file is quicker if it gets around her problem.

Those are all good calls. Yeah, I didn't want to waste more time on it. The batch file worked and I'll leave it at that.