Freitag, 27. Juli 2012 10:03
This is an old story, a problem with many different solutions on line. But I've tried 'em all and none have worked for me yet. I'm hoping someone can give another suggestion.
I have an old Red Hat Linux box that I use, amongst other things, to run Samba (vsn.2.2.3a). My Vista and Win XP PCs can access the p/w-protected Samba shares but a new Windows 7 Ultimate 64-bit PC cannot.
All are on a workgroup-only LAN - no domain. UAC is turned off.
I can see the Linux box's icon and shared directories in 'Network' from the Win 7 machine but when I try to access a Samba share it says "\\LX\roy is not accessible. You might not have permission to use this network resource." etc. But the XP and Vista boxes still have full access.
After each change tried, I rebooted the Win7 box. These are the steps I've taken, based on suggestions found in threads here and elsewhere on the Web:
1. Start > RUN > control userpasswords2 > Advanced > Manage Passwords to ensure that \\LX\roy password is set correctly and is the same as for XP and Vista PCs. If I remove the password here, I can't see the shared directories on the Samba box - it asks for credentials. I give it the name and password, then it lets me see the shared directories. But when I double-click on one of those, I get the 'not accessible...' message. The same name and password give me full access when typed from an XP or Vista box.
2. With gpedit.msc > Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Microsoft network client: Send unencrypted password to third-party SMB server: Switched to "Enabled".
2b. and then set Network security: LAN Manager authentication level: Set to Send LM & NTLM - use NTLMv2 session security if negotiated.
2c. I also tried "Send LM & NTLM responses". This seems to be the solution that works for many people with this problem, but not for me.
2d. and then set Network access: Sharing and security model for local accounts: Classic – local users authenticate as themselves.
2e. Minimum session security for NTLM SSP are both set to 'no minimum' for both clients and servers.
An image showing all my local security settings is here: http://www.gandanet.com.hk/local_security_policy.png
3. I checked or changed these registry keys KEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa and found that LmCompatibilityLevel was already set to 1 (perhaps by action 2).
3a. Based on another suggestion, I changed it to 2 ... This made no difference.
3b. I added this, (based on J Paige's solution here: http://social.technet.microsoft.com/Forums/en/w7itprosecurity/thread/e30589d3-ab5a-4233-a199-7d5caf395875)
"AllowNT4Crypto"=dword:1 -allow less secure encrypted passwords (intermediate keys must be created)
4. I tried making my Win 7 password the same as my Samba p/w (the user name was already the same). Same result.
5. I set up Windows XP Mode in a Windows Virtual PC, because I read (http://social.technet.microsoft.com/Forums/en-US/w7itprovirt/thread/e08c3500-a722-4b44-b644-64f94f63c8e5/) that giving the share a drive letter in Windows XP Mode makes that drive letter available in Win 7 as well. But that doesn't work for me - XP mode does indeed have access to the Samba shared directories through a drive letter, but I do not see the drive letter in Win 7, and accessing the shares from Win 7 does not work, even if I set up .
6. Based on a suggestion here: http://social.technet.microsoft.com/Forums/en-US/w7itpronetworking/thread/ebc46c02-09df-4c8a-82b8-d1e4e0a8eddd I tried a batch file like this:
That completes successfully, but when I try to open Z:, it tells me that Z: is not accessible, Access is denied.
7. I've run Wireshark, but it doesn't tell me much as don't know how to interpret its output. I see [Malformed packet] messages, which perhaps may mean that the packet is encrypted but Samba doesn't expect it to be.
8. After a suggestion from @Elliot90210, I checked the "TCP/IP netbios helper" service, but found that it was already started and that its startup type was set to Automatic.
9. Here's an extraordinary finding, which might offer a clue to the knowledgeable:
I have a share set to drive Z: When I double click on it, I get a message:
Z:\ is not accessible.
The specified server cannot perform the requested operation.
But Windows Explorer in Win 7 shows it as a network drive with a green indicator and shows the space free and total space on that drive.
If I run Beyond Compare, and point it at Z: it doesn't give an error message, and can show all the folders and files in the drive, but it cannot read, write or delete them. So it seems to have more permissions than my user account, but not enough to be useful.
The Linux box does part of what I need for ecommerce - the in-house part, it's not accessible to the Internet. As my Linux Fu is weak, I have to avoid changes to the Linux box, so I'm hoping someone can tell me what to do to Win 7 to make it behave like XP and Vista when accessing this share.
Can anyone help me with any ideas, beyond all the above?
- Bearbeitet Roy Grubb Montag, 30. Juli 2012 07:56
Freitag, 27. Juli 2012 16:55Take a look at which services are on. I was unable to access samba shares from this windows 7 pc, even its own ones that were accessible from other computers. Then today I switched on the "TCP/IP netbios helper" service and it worked.
Samstag, 28. Juli 2012 07:16
Thanks Elliot, sounded like a hopeful idea.
I checked and found that the service was already started, and its startup type was set to automatic. So, disappointingly, no luck still.
Thanks for taking time to make the suggestion though.
Montag, 30. Juli 2012 09:38
I have a little confusion about the point 9. You mentioned the drive Z can show all the folders and files in the drive, but it cannot read, write or delete them. Do you mean the drive Z mappes to the Samba share? Does you mean that you can access \\LX but cannot access \\LX\roy?
Montag, 30. Juli 2012 10:58
Sorry, I made a further discovery and a correction to the above text, but you obviously caught it before I made the change. The current situation:
I can see \\LX in Windows Explorer under Network.
If I select LX, I see its shares, including 'roy' in WE
If I double click on 'roy' in WE, I get the '... not accessible ... you might not have permission ...' message
If I right click on 'roy' in WE, and select 'Select Left Folder for Compare' (a context menu item Beyond Compare adds) then right click again and select "Compare to 'roy', Beyond Compare opens and can see everything in 'roy' but with read access only.
It seems that BC might have access as SYSTEM, but even if it does, it can't delete or write.
Meanwhile from XP Mode on the same PC, I have full read/write/delete access to '\\LX\roy' and Z:\ using WE.
- Bearbeitet Roy Grubb Montag, 30. Juli 2012 11:31
Dienstag, 31. Juli 2012 06:56
Could you please capture upload the network trace on the client side when you reproduce the issue so that I can try to check it?
Dienstag, 31. Juli 2012 08:24
Thanks for staying with this Scott,
I used Wireshark to capture network activity in promiscuous mode while I double clicked in WE on the shared folder under the server in Network. Then I double clicked on Z:\ The messages mentioned before appeared in each case, of course.
Before doing this, I closed apps and services that might try to access the network but not be relevant to this problem (browser/email/Tweetdeck etc.) to reduce irrelevant activity.
Can I email the capture file to you? It contains control characters as well as text, so I can't copy and paste it here - and anyway, I'm not sure if it would contain info that might compromise our network if available publicly.
- Bearbeitet Roy Grubb Montag, 10. September 2012 10:50
Mittwoch, 1. August 2012 07:46
OK, please email the logs to email@example.com and I'm glad to have a check at it. Please also inform me the IP address of the client and server.
Mittwoch, 1. August 2012 09:32
Have emailed the trace, thanks Scott.
Actually two traces and a couple of explanatory images.
Donnerstag, 2. August 2012 05:35
For the record, I had a suggestion from another forum that I should disable SMB 2.0 on the Windows 7 box, using the following commands:
In Command Prompt with Elevated Mode:
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
Note there's an extra " " (space) after the "=" sign.
I tried this, restarted the machine, but found no difference - I still get the same messages when trying to access the Samba shares.
Also for the record, I re-enabled SMB 2.0 like this:Command Prompt:
sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto
Again, note there's an extra " " (space) after the "=" sign.
Freitag, 3. August 2012 07:06
I check the network trace you sent me.
You can see that the server replied "STATUS_NETWORK_ACCESS_DENIED" to the client. It means that the user you log on the windows 7 doesn't have NTFS permission to the share on Linux machine. Do you use the same account to log on the windows 7 and windows XP?
Freitag, 3. August 2012 09:09Hi Scott,
I do use the same account name and password on Windows XP PCs (not XP Mode) and the Windows 7 PC. XPMode allocated the name XPMUser automatically when I installed XPMode and I set the same password for that as for 'roy'.
But I don't think that should affect access to the Linux box, because I use the same account name (roy) but different password on the Linux machine, and I supply the Linux account password when asked for it by the Linux share.
However, I just tried this to verify: In XP Mode, I logged off XPMUser, logged in as roy with the same password as I use in Windows 7. I found that I could still access the Linux shares, whether logged on as XPMUser or as roy.
I have double-checked my Windows 7 password, by 'changing' it to the value it already has. As the change requires the existing password before it will accept the 'new' one, and that was accepted, I was able to confirm that there was no error there.
In addition, I have previously tried setting my Windows 7 account password to the same one used in the Linux box so that the account credentials are identical on both machines, but that makes no difference. I don't use Kerebos or any other pass-through mechanism. And I just tried this again, in case any of the other changes I have made might have got me past the log-jam, but no luck.
I have tried two ways of providing the Linux account password:
1. control userpasswords2 > advanced > manage passwords > windows credentials > CONVENSRV03 > Remove from vault > yes
click on CONVENSRV03 under Network in WE
Dialog asking for User name and Password appears (at this point I cannot see the shared Linux directories)
I enter roy and Linux account password, and click Remember
click on CONVENSRV03 under Network in WE again
I can see all five shared directories (in other words the Linux password has been accepted)
double-click on one called share
the 'not accessible' message appears (as it does for the others if I try them). My Linux account normally has access to all five.
2. control userpasswords2 > advanced > manage passwords > windows credentials > CONVENSRV03 > Edit
User name appears as BLACKADDER\roy
I change it to just roy
re-enter Linux account password
click on CONVENSRV03 under Network in WE again
double-click on directory called share
the 'not accessible' message appears
So whatever I do, I can't seem to get this to have the necessary rights, and I don't understand why my Linux account credentials, that work everywhere else are not being passed through to Samba in a form that the Linux box can understand.
Thanks and best regards.
Freitag, 3. August 2012 14:38
this how you did the shares?
Freitag, 3. August 2012 15:35
I don't know how it was done - it was set up by someone else years ago. It's an old version of RedHat and was more than likely done from the command line. The share is owned by root, but is accessible on the network to all users with an account on the Linux box - except in Windows 7.
Freitag, 3. August 2012 16:55
i'm thinking its a setting with the linux box and not windows 7...
Not to sound like an a** with this question but...
How do you know it is accessible on the network to all users then if you dont know how it was set up on the redhat box?
According to that link you have to acces it with the samba username and password. Or you can share without username and password it's up to you.
Try with the windows 7 station using the IP of the box to connect to the share instead of the name of the share. Use ifconfig from the command line of the linux system to see the ip
Samstag, 4. August 2012 03:01
Hi Ang101,I know it is accessible on the network to all users because all users have access via WinXP and Vista and have had for years, added to which, I have their names and passwords and can try for myself. This sever has been active for years with XP and Vista clients with no problems. It's only when we got a Win7 machine that access became a problem.
If I try to access \\192.168.0.128\share it asks for the name/password, which I supply, then I get the same 'not accessible' message. If I do the same thing on a Vista box, it opens OK.
Montag, 6. August 2012 12:20
In the Local Group Policy Editor, go to:
Policy->Computer Configuration->Windows Settings->Security
Settings->Local Policies->Security Options
Microsoft network client: Digitally sign
If this is enabled, change it to
Disabled. Be sure and restart your machine for the change to take effect!
Pressing the "Apply" button in the Policy Editor after the change is made is not
Once I did this, I was able to access my Samba
Hopefully this will help someone else who runs into the same
Thanks to those who attempted to help me
found this on another forum. worth a shot
Montag, 6. August 2012 12:30another question too if that doesnt work...what exactly are you putting in for the user? are you putting DOMAIN\User? whatever domain is here?
- Bearbeitet Ang101 Montag, 6. August 2012 12:30
Montag, 6. August 2012 13:37Hi, Ang101,
Microsoft network client: Digitally sign communications (always)
was already set to Disabled
Microsoft network client: Digitally sign communications (if client agrees)
was enabled, and I even tried disabling that and restarting, but it made no difference. I would have been surprised if it had worked, but still....
An image showing all my local security policy settings is here.
> are you putting DOMAIN\User? whatever domain is here?
I've tried just "user", and "MACHINE\user" (it's in a workgroup rather than a domain). What I've found is that it comes back with MACHINE\user either way.
It is (sort of) accepting the credentials, because if I use control userpasswords2 to delete my user & password associated with CONVENSRV03 (the real name of the Linux box which I shortened to LX above for simplicity), I can't see the shared directories. When I click on CONVENSRV03 under Network, it asks for the credentials. I give them, and then it will show the shared directories, so it considers them valid. But when I double-click a shared directory on CONVENSRV03, it comes up with the message:
"\\CONVENSRV03\share is not accessible. You might not have permission to use this network resource. Contact the admin....etc.
"The specified server cannot perform the requested operation."
The latest thing I've tried, taking my life in my hands, is to remove encryption from Samba passwords. I saved copies of the existing smb.conf and smbpasswd elsewhere.
Then in smb.conf, I changed
encrypt passwords = Yes
encrypt passwords = No
unix password sync = Yes
unix password sync = No
Then, in /etc/samba I deleted smbpasswd, restarted the machine, and set up my Samba account with the same password as before.
After this, neither Windows 7 nor Vista could access the share - they could see the server, but could not even display the shared directories, and did not ask for credentials. I re-instated the Smb.conf and smbpasswd files and restarted the machine again.
As usual, a Vista PC could then access the shares, but not Win7.
- Bearbeitet Roy Grubb Montag, 6. August 2012 14:26
Montag, 6. August 2012 18:37
hmmm...interesting that all seems right there.
ok a few more things to try just to make sure it's not something silly.
Turn off the windows firewall if its not already. And make sure the stop the service after you turn it off.
Do you have any other firewall or something that could be affecting it?
Something else to try would be...
on the samba server make a new share (if you can do this) and test with this one. Start with a clean blank share and maybe some configuration done a long time ago to that samba share is screwing with something.
Dienstag, 7. August 2012 07:05I had tried turning Windows Firewall off at a very early stage in my investigations, but I hadn't realized that this wouldn't stop the service immediately, so I just gave it another try. After stopping the service, the Samba share was still not accessible.
On the question of other firewalls, I did originally install an old version of ZoneAlarm, my favorite firewall for XP, but it didn't function as a firewall on Win 7. After installation, I found it just let programs access the network without asking. So I uninstalled that and deleted all its program files.
Your question makes me wonder if ZoneAlarm had corrupted the IP stack in some way, so I did
netsh int ip reset c:\resetlog.txt
but after a restart, it turned out that made no difference either. Oddly, it didn't write anything in c:\resetlog.txt, but it showed three success messages in the cmd window.
I did try making a new share on the Linux box yesterday. It appeared and was writeable in Vista and XP Mode, but as with the others it was visible and not accessible from Win7.
I have a Fedora server for experiments, and Samba shares on that are accessible, so it seems it must be something to do with the version of Samba, 2.2.3a, I'm using and Win 7's interchage of credentials.
Dienstag, 7. August 2012 12:23
I am using Samba 3.0.25b and have the same problem on all new machines that came recently with Win7 Pro Sp1 images. Old machines, even with SP1 applied through Ms update, have not this problem and can login and browse private folders on Samba shares normally.
On one of these three computers I was able to solve problem by deleting actual shares from net use table and establishing network drive with "different" credentials (in fact they are the same, however). From that point this computer was able to access private folder. But the same method did not worked on other two computers, even one of them is absolutely the same like the one it worked on.
Now I am little confused...
Dienstag, 7. August 2012 14:26
Well I'm thinking this a problem with samba versions and windows 7 now.
Have a look here and see that most of the samba server versions they say that work with win7 is 3.2+.
Dienstag, 7. August 2012 21:09I've been following this thread with interest as I have a similar problem. My home server runs FreeNAS 8.2.0-RELEASE-p1 (Samba 3.6.5) and the CIFS shares can be accessed from my Windows XP and openSUSE 12.1 machines but not by my wife's laptop with Windows 7 Professional. She can see the shares but trying to access them results in "You might not have permission to use this network resource" etc...
I have progressed through several versions FreeNAS (and therefore Samba) but the problem persists. So far I have tried everything suggested in this thread but like the OP nothing is solving the problem...
Mittwoch, 8. August 2012 03:32
@Ang101 thanks, that's revealing. It didn't turn up anywhere near the front with my original Google search.
Today, I'll try those registry keys, and @Jiri's 'delete shares' idea. If that doesn't do it, I'll Ghost the server, and try to update Samba. If it screws up, I'll only have to Ghost it back.
This may take a while, but I'll report back for others with the problem.
When/if, I eventually get a solution, I'll summarize all the things I've tried in single post - more useful than this long thread.
Mittwoch, 8. August 2012 06:24I tried adding the keys to registry and removing the entries from the net use table but neither idea worked for me I'm afraid...
Freitag, 10. August 2012 11:27Adding the registry keys did not work for me either.
So I followed the route of Ghosting the disk, and installing a later Samba rpm. I settled for samba3-3.2.15-41.el5.i386.rpm as it was the earliest I could fine that, according to http://wiki.samba.org/index.php/Windows7 was capable of talking to Windows 7. I found it here:
I wanted the earliest I could find, because my version of RedHat is really old, REdHat 7.3 professional (not Enterprise), Linux kernel, 2.4.18-3.
Unfortunately, I ran into a heap of dependency problems, listed later. By that stage, not suprisingly, no Windows client could see the Linux server, so I ghosted it back and restarted it. It's running OK, and WinXP and Vista have access as before.
So following instructions at http://forum.soft32.com/linux/Samba-download-ftopict349212.html I did:
rpm -qa | grep samba
so I did:
rpm -e samba-common-2.2.3a-6
rpm -e samba-client-2.2.3a-6
rpm -e samba-2.2.3a-6
rpm -ivh samba
That didn't work - "error: open of samba failed: No such file or directory"
so I tried:
rpm -Uvh /usr/src/redhat/RPMS/i386/samba3-3.2.15-41.el5.i386.rpm
error: failed dependencies:
libacl.so.1 is needed by samba3-3.2.15-41.el5
libacl.so.1(ACL_1.0) is needed by samba3-3.2.15-41.el5
libattr.so.1 is needed by samba3-3.2.15-41.el5
libattr.so.1(ATTR_1.0) is needed by samba3-3.2.15-41.el5
libc.so.6(GLIBC_2.3) is needed by samba3-3.2.15-41.el5
libc.so.6(GLIBC_2.4) is needed by samba3-3.2.15-41.el5
libc.so.6(GLIBC_2.5) is needed by samba3-3.2.15-41.el5
libgssapi_krb5.so.2(gssapi_krb5_2_MIT) is needed by samba3-3.2.15-41.el5
libk5crypto.so.3(k5crypto_3_MIT) is needed by samba3-3.2.15-41.el5
libkrb5.so.3(krb5_3_MIT) is needed by samba3-3.2.15-41.el5
liblber-2.3.so.0 is needed by samba3-3.2.15-41.el5
libldap-2.3.so.0 is needed by samba3-3.2.15-41.el5
libpam.so.0(LIBPAM_1.0) is needed by samba3-3.2.15-41.el5
libwbclient.so.0 is needed by samba3-3.2.15-41.el5
rtld(GNU_HASH) is needed by samba3-3.2.15-41.el5
samba3-client is needed by samba3-3.2.15-41.el5
I suspect at this point I shan't be able to update Samba on this installation without getting into a long chain of dependencies.
Freitag, 10. August 2012 11:44virtualization? and install a newer version of redhat on a test virtual machine with updated samba
Freitag, 10. August 2012 15:02
I'v a feeling I'd rapidly get out of my depth there .... the successful re-ghosting makes me feel safer than before about experimenting, though.
I'll look into installing Fedora in a VM.
Do you know if old versions of Linux support VMs?
I wonder if the virtual m/c have access to the Redhat drives, and could it then pass a share through?
Many thanks for your help.
Freitag, 10. August 2012 17:04
i think most old versions do. a lot of the drivers are compatible.
I don't know about passing a drive through, I'd just try it on the Redhat drive to see if it works with windows 7. Then you know if you have to update the old share
- Bearbeitet Ang101 Freitag, 10. August 2012 17:04
Samstag, 11. August 2012 06:20
My thanks to @ScottXi and @Ang101 for all the time they put in and help they offered me. It was much appreciated.
I shall now disappear for a while as I try to install a VM on Redhat, and Fedora in that - if I can find out how in both cases.
Montag, 13. August 2012 19:58
Dienstag, 14. August 2012 04:00
What I've been told on unix.stackexchange is that "Red Hat 7.2 is a 2001/2002-era operating system released far beforeLinux kernel-based virtualization was an option."
I'll try over time to build a CentOS or Fedora server with all the apps and batch files that service the e-commerce function. Meanwhile, I guess I just have to hold off on installing more Win7s and instead keep some XPs running to give us access.
Freitag, 17. August 2012 11:41
update of mine situation.
One of these new notebooks crashed to blue sreen two days ago due problems with hardware, and I was unable to recovery it by standard Win7 ways. It is new computer for new employee and it had just standard software packet installed and none user specific data (they should be stored on server anyway). So I decided to make factory state recovery and start over from here.
Weird thing is that, after factory state recovery and following customisation phase, it was able to join our private shares without any problem. I also just installed another computer that came with Win 7 Pro SP1 image installed and it has none problem either.
I still need to find solution for these two HP ProoBook machines, however. Reinstallation is not easy way here as they have complicated user specific software packages installed already.
I am also afraid to upgrade Samba version on our file server because it is linux driven NAS box with obsolete maintenance agreement and even I have root access I am not sure about dependencies. It is running proprietary management module that is essential for its administration and I do not know enough about it to make any great changes to system config or structure.
Freitag, 17. August 2012 15:06
I'm currently building a new linux server (based on Ubuntu) as the only solution that I can see that is sure to work, if I can get my head round everything that needs to be done.
Mittwoch, 29. August 2012 09:45
I have the same issue. NAS drive with samba shares mounted. Can access fine from XP. Get "not accessible" error from Win 7. Win 7 detects the NAS, can see the volumes and properties, but will not open. I tried all that you did, as well, with no success.
Have you found any solutions? It's very strange and frustrating....
Mittwoch, 29. August 2012 10:43
No, sorry, I haven't.
I'm currently building a new server with Ubuntu 12.04, and although that does solve the Samba access problem (as expected), I am still working on getting all the server's other functions operating correctly. That's proving difficult, probably because so many things are running with much later versions of PHP, MySQL and so on.
Until I do, I need to stick with the old server which means no access from Windows 7.
Mittwoch, 29. August 2012 17:39
Hi Roy - did you try disabling IPv6 on the NIC?
I'm not at my problem PC, so I haven't tried it yet, but I will see if that works tonight. Just thought I'd throw that at you, since I didn't see it in any of the above possibilities...
Donnerstag, 30. August 2012 04:49
That wasn't a solution for me, but it was interesting and puzzling.
If I disable IPv6 through the check box for the Internet Protocol Version 6 (TCP/IPv6) component in the list of items on the Networking tab, I loose all access to the LAN. The IPv4 entry is still checked, but when I click on Network in WE it says that Network discovery and filesharing are turned off. When I follow the advice to "Click to change..." and click through to turn it back on, it has no effect. Local Area Connection Status shows "No network access" against both IPv6 Connectivity and IPv4 Connectivity.
Checking the IPv6 entry sets everything back to normal.
So then I followed the "Let me fix it myself" instructions on the MS page you linked to, to edit the registry. I added a DisabledComponents entry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters and set it to ffffffff.
Strangely that made no difference to my access to the LAN, unlike when I unchecked the IPv6 box. But, even after rebooting, it didn't give me access to the Samba 2.2.3 shares either. So finally I deleted that added registry entry.
- Bearbeitet Roy Grubb Donnerstag, 30. August 2012 04:57
Donnerstag, 30. August 2012 15:39
Ditto - it didn't work for me, either. I actually had this problem last year when I first installed Win 7 on this same laptop, but I don't remember how I fixed it. My friend thinks he remembers that reinstalling Windows did the trick, but that just makes no sense to me. If I just installed Windows 7 and it doesn't work, why would reinstalling it again suddenly work? But, maybe I'll just bite the bullet and start over.
It just makes no sense that I can map the drive, view the volumes, see the properties, etc..but have no access to read/write.
So very frustrating.
Donnerstag, 30. August 2012 17:33
You know what? I think I remember something. Try uninstalling Win 7 SP1. Reboot, then try to get to your samba share. If that does work, then reinstall SP1 and check again to verify that your samba share sticks. I THINK that's what I did.
And THAT would explain why reinstalling Win 7 worked - because I tried to get to the share BEFORE going on with all the updates..... HMMM
Oh, and do the SP1 update through Control Panel, not through the update website.
I can't try it myself, because I have Win 8 beta on top of my Win 7, so I can't go back to uninstall SP1 without starting over.
- Bearbeitet maloKT Donnerstag, 30. August 2012 17:56
Freitag, 31. August 2012 02:41I have confirmed that I can successfully browse my samba shares with a fresh install of Win 7 and no SP. I will install patches and SP1, testing after each, to narrow down which is the culprit.... hope this helps you, too.
Freitag, 31. August 2012 03:02
So, I will be installing all but that KB, then verify samba connectivity. Keep you posted.
- Bearbeitet maloKT Freitag, 31. August 2012 03:13
Sonntag, 2. September 2012 21:05Success. Try uninstalling KB2536276. :)
- Als Antwort markiert Roy Grubb Montag, 3. September 2012 04:19
Montag, 3. September 2012 04:19Yahay! That was it!!
For others' reference, these were the steps:
I went to
Windows Update > View update history > Installed Updates
and searched for KB2536276. It was well down the list in the "Microsoft Windows" section (the Search Installed Updates box couldn't find it)
> Uninstall > Restart
Then I could access my old Samba shares. And I checked to make sure it hadn't messed up access to other Windows boxes, and the new Ubuntu server I was working on building - they were all OK as well.
[Update: I forgot to mention that anyone doing this should ensure that Windows Update is set to "Check for updates but let me choose whether to download and install them", and then, when WU again wants to install KB2536276, right-click that item and choose "Hide". Otherwise you'll be back where you started.]
Thanks to @maloKT for finding the solution that worked for me, and to @Ang101, Scott Xi - MSFT for their suggestions and effort in digging out possibilities.
- Bearbeitet Roy Grubb Mittwoch, 5. September 2012 04:01
Mittwoch, 5. September 2012 01:40
So glad it worked for you! Don't upgrade to Win 8 - lol - I guess that patch is built into Windows 8, and now I can't get to my samba shares again. Back to 7 for me... ;)
EDITED: Heh, so I downloaded WinSCP just to see if I could browse my samba shares that way....and voila...work around for Windows 8 until a real fix is found. Or, I may just need to update my Samba version on the router, as I think the patch closes vulnerabilities in the older Samba release. Anyway, at least we can get to our stuff now. :)
- Bearbeitet maloKT Mittwoch, 5. September 2012 02:07
Mittwoch, 5. September 2012 03:56
No fear of me going to 8 - not unless it has a lot of changes (I hate the interface-formerly-known-as-Metro!).
For the new machine I have been having trouble with here, I paid extra for a box set Windows 7 instead of OEM Windows 7 precisely because when I next upgrade, I want to avoid being forced onto Windows 8.
Thanks for the tip about WinSCP, btw.
Donnerstag, 1. November 2012 13:21Same problem, uninstalled this update did not resolve this... might try uninstalling sp1
Donnerstag, 1. November 2012 17:25
There are many solutions in this thread. Although the one that worked for me was right at the end, other people solved the problem with a different approach that didn't fix it for me. Have you worked through the earlier suggestions?
Montag, 12. November 2012 06:29
Why not upgrade to a current Samba version that properly supports Windows 7 instead of uninstalling critical security updates, removing service packs and disabling security settings?
Montag, 12. November 2012 07:19Why not read my original question to find out, perhaps?
Dienstag, 11. Dezember 2012 21:11
I have been reading through all these post but I am yet to find a solution to my problem. It is exactly the same as what is described at the top of this thread. Except I am trying to connect to a standalone Linux based NAS drive/caddy. Due to the nature of this an upgrade to firmware isn't an option (it is unbranded). I have tried all the suggestions from the windows 7 end. I don't have any problems with windows XP.
The NAS is set to No Password mode I'm suspicous that windows 7 may not like this.
I have ran wireshark but nothing jumps out at me.
If someone is willing to look over my wireshark logs and make some suggestions that would be great. I can email them, or however you would like them sent.
Sonntag, 17. Februar 2013 10:59I experienced the very same problem and it took me a looong time to solve.
Windows 7 Ultimate 64 Bit
Iomega StorCenter ix4-200d 8 TB NAS
Network Membership: Workgroup
IP connectivity: all devices in same subnet
Unable to map / connect to NAS SMB/CIFS Shares (public AND password protected)
Workaround until solved:
Using NFS Mounts
My Windows 7 laptop had initially been a Domain member and configured with fairly strict security policies. When I removed laptop from domain, I naturally browsed through policies and changed the most obvious ones but was unable to solve the problem. After capturing network traffic and filtering SMB negotiation error messages, I realized the client (Windows 7) after NTLM authentication prosess was complete, requested something that NAS/Samba was unable to complete.
The policy I had missed:
Microsoft network client: Digitally sign communications (always) | Enabled
This policy is most often defined/enabled in corporate Domain environments because SMB packet signing makes sence and provides additional security. However my NAS was unable to complete the request. After disabling the policy, problem was solved.
So for me it was not a problem of authentication, but packet signing.
Just thought I'd share this solution as well.