kabirbedixy: Windows 7 + Linux Samba sharing problem

Updated: November 2, 2012

The situation you are facing is like this: You have successfully used Samba sharing in Linux to access Windows XP shares on your local network. It worked without any problems, including by name and/or IP address. You could open the shares and write to them.

Since migrating to Windows 7, you are seeing a weird problem. Your Samba sharing no longer works. In Nautilus, you get a very generic error that says: failed to access share. You are not a clueless user and you know all about permissions, firewall and all that. To make the situation worse, the sharing might work on some Windows 7 boxes, but not on others. So you feel worried and think what to do next. You hit the Internet and get advice on how to add wins to your nsswitch.conf and how to edit the Samba configuration and all that. Not necessarily what you want to do. I've got a better idea. Read on.

Teaser

Situation report

This happened to me. I have two new Windows 7 boxes in my LAN, one the high-end gaming computer I've written about last year, and another, almost identical machine recently added to the arsenal. So you might assume, two identical machines, the same operating system, what could go wrong? The answer is, something.

XP access was fine, Windows 7 is not, for some reason - on only one machine. What do you do next?The answer is - you do not blindly follow advice written in forums, because every single problem is oh-so-slightly different than yours, so you end up doing things that will change your system beyond repair and confuse you even more. It is important not to be tempted to try to resolve things quickly but smartly, and figure out what you should do.

Here's the list of things that you should NOT do:

There's no reason for you to play with the Samba configuration. Because the Samba configuration is relevant for your own shares, not the ones you are trying to access on another computer. Besides, it worked in the past.

There's no reason to change the resolve order of your box, under /etc/nsswitch.conf, because the same configuration worked well before. On the network level, you are just fine. Moreover, adding wins randomly before or after dns or suchlike could slow down your network performance. Moreover, /etc/fstab plays no part here either.

In theory, yes, all of these could be problematic. You might need winbind package and you might have to configure smb.conf and all sorts of things. But think! Your Linux has not changed in any way, and it worked before! Or it works with some Windows 7 machines, but not others, even though all settings seem to be identical! And therefore, the problem is most likely 100% isolated to the new specific Windows system you've introduced to your setup.Do not change things and worsen the situation. Wait.

What it might be?

A firewall could pose a problem, but on the Windows box. Do check that one. Please see my other Windows 7 sharing woes article for more details on the little configurations and tweaks for healthy LAN traffic. It's not your Linux firewall, anyway.

Firewall

Permissions might be in order, but most likely not. The right user, probably not. You're using Linux, you are a geek, these trivial checks are not what's troubling you. Yes, there could be a million other reasons, but the premise in this article is that you are not changing the world, just one operating system that shares its stuff. Hence, accordingly, your users and permissions should be set the same way as before. But I'm not here to discuss operational blunders, I want to show you how to think and solve problems.

So what it is then and what do we do?

Solution

First, go command line. Linux is helpful that way. Try accessing shares from the command line and see if you get anything meaningful. So to check whether you can even access the relevant Windows share, type:

smbclient -L windowsbox

You will get an error. My guess, and I bet you a million yens that you will see the following error message on your terminal screen:

protocol negotiation failed: ERRnomem

Excellent. Progress. Let's try to understand what's happening here. Protocol negotiation means your Samba client is capable of reaching your Windows box, with the right credentials and permissions. However, the Windows box is incapable of returning your query, complaining about no memory, it seems. So how about we check the Windows machines and figure out if there's anything in the Event log there?

Indeed, on the Windows 7 box, you see this:

Event 2017, srv: The server was unable to allocate from the system nonpaged pool because the server reached the configuration limit for nonpaged pool allocations.

srv error

All right, now that you know what the problem is all about, you can go about the Web and get the necessary information. Once you have the exact Event ID, the resolution is trivial. It turns out that the Windows box does not have enough memory to allocate to your requests, as silly as it sounds.

Therefore, how do you resolve the Event ID 2017? You will need to open the registry editor and make two changes. No need to reboot or anything, the change will take place on the fly.

First, navigate to:

Computer\HKLM\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters

And changeSize from 1 to 3.

Regedit change 1

Then, navigate to:

Computer\HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management

And change LargeSystemCache from 0 to 1.

Regedit 2

And now, you will have a sane, expected Samba behavior.

Conclusion

I may come off as an angry, all-knowing nerd in this article, but that's exactly the point. Sometimes, problems are far simpler than they appear. Rather than doubting your operational setup that has served you loyally all these years, you should immediately doubt the new changes added to the environment. Do not start editing configuration files, installing software and disabling services and components in a blind hope to get something going.

As this particular case illustrates, when faced with a stupid problem, so to speak, you should refrain from making too many changes that will only complicate the situation. Try using the command line if possible and reading system logs to get some kind of an error message or a code number. Once you get there, the rest will be trivial. I hope I helped you there, and if not feel free to ignore me.

Cheers.

RSS Feed icon