If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#1
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
Here's the situation. I have a Win7 machine that has been running fine for
many years. It has a shared directory that is accessed on the home LAN by many clients - mostly Linux machines, but including one Windows XP box. This machine is up pretty much "all the time" and is rarely rebooted. The Win7 machine was rebooted 9 days ago. I think this is the triggering event, although the effects did not show up until today. Today, I found that older clients (the Linux boxes running older versions of Samba and the XP box) cannot connect to the Win7 share. I first noticed this by noting that existing connections had stopped working, and when I unmounted and attempted to remount, got error "Remote IO error" and the Samba mount failed. On XP (using "net use"), the error message is "The remote server cannot perform the requested operation". However, 3 of my Linux boxes continue to work fine with the share. They are all running up-to-date versions of Linux and Samba. Note, of course, that upgrading the older machines is not an option; if it were, I would just do that (and wouldn't be posting this). What I need to do is to fix the Win7 side so that it works as it did before. I know that Samba was recently "upgraded" to a new protocol for some "security" reason, such that sometimes you have to use "vers=1.0" on the client side to make it connect to older servers. This situation seems to be the "inverse" of that - i.e., the server is only accepting clients that speak the new protocol. What I think is going on is that the Win7 machine modified itself (probably as a result of the reboot) so that it no longer accepts version 1 client requests. What I need is to know what to tweak to change that back - so that it will work with the older clients as it did before. Anyone have any ideas? Serious replies only, please. I think I've tried all the "baby" things, like in the "Is it plugged in?" variety. -- Conservatives want smaller government for the same reason criminals want fewer cops. |
Ads |
#2
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
On 2020-03-30 20:28, Kenny McCormack wrote:
Here's the situation. I have a Win7 machine that has been running fine for many years. It has a shared directory that is accessed on the home LAN by many clients - mostly Linux machines, but including one Windows XP box. This machine is up pretty much "all the time" and is rarely rebooted. The Win7 machine was rebooted 9 days ago. I think this is the triggering event, although the effects did not show up until today. Today, I found that older clients (the Linux boxes running older versions of Samba and the XP box) cannot connect to the Win7 share. I first noticed this by noting that existing connections had stopped working, and when I unmounted and attempted to remount, got error "Remote IO error" and the Samba mount failed. On XP (using "net use"), the error message is "The remote server cannot perform the requested operation". However, 3 of my Linux boxes continue to work fine with the share. They are all running up-to-date versions of Linux and Samba. Note, of course, that upgrading the older machines is not an option; if it were, I would just do that (and wouldn't be posting this). What I need to do is to fix the Win7 side so that it works as it did before. I know that Samba was recently "upgraded" to a new protocol for some "security" reason, such that sometimes you have to use "vers=1.0" on the client side to make it connect to older servers. This situation seems to be the "inverse" of that - i.e., the server is only accepting clients that speak the new protocol. What I think is going on is that the Win7 machine modified itself (probably as a result of the reboot) so that it no longer accepts version 1 client requests. What I need is to know what to tweak to change that back - so that it will work with the older clients as it did before. Anyone have any ideas? Serious replies only, please. I think I've tried all the "baby" things, like in the "Is it plugged in?" variety. Have you tried accessing the share by IP address, instead of share name? \\win7_share\public \\192.168.1.1\public Every so often, that is the only way I can get things to share, and for the life of me, I can not figure out what is wrong. Then a few months later, I come back, and I can use shared names. |
#3
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
On Tue, 31 Mar 2020 03:28:16 -0000 (UTC), in alt.comp.os.windows-10,
Kenny McCormack wrote: Here's the situation. I have a Win7 machine that has been running fine for many years. It has a shared directory that is accessed on the home LAN by many clients - mostly Linux machines, but including one Windows XP box. This machine is up pretty much "all the time" and is rarely rebooted. The Win7 machine was rebooted 9 days ago. I think this is the triggering event, although the effects did not show up until today. Today, I found that older clients (the Linux boxes running older versions of Samba and the XP box) cannot connect to the Win7 share. I first noticed this by noting that existing connections had stopped working, and when I unmounted and attempted to remount, got error "Remote IO error" and the Samba mount failed. On XP (using "net use"), the error message is "The remote server cannot perform the requested operation". However, 3 of my Linux boxes continue to work fine with the share. They are all running up-to-date versions of Linux and Samba. Note, of course, that upgrading the older machines is not an option; if it were, I would just do that (and wouldn't be posting this). What I need to do is to fix the Win7 side so that it works as it did before. I know that Samba was recently "upgraded" to a new protocol for some "security" reason, such that sometimes you have to use "vers=1.0" on the client side to make it connect to older servers. This situation seems to be the "inverse" of that - i.e., the server is only accepting clients that speak the new protocol. What I think is going on is that the Win7 machine modified itself (probably as a result of the reboot) so that it no longer accepts version 1 client requests. What I need is to know what to tweak to change that back - so that it will work with the older clients as it did before. Anyone have any ideas? Serious replies only, please. I think I've tried all the "baby" things, like in the "Is it plugged in?" variety. First, try this on the Win 7 machine. sc.exe qc mrxsmb10 If the response is "The specified service does not exist as an installed service." then you don't have SMB 1.0 installed on your machine at all. If it's there, this line will bind SMB 1/2/3 to your Workstation service. sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi Any time you change depend= this way it overwrites the entire dependency tree. You can't append to it, you can only overwrite it. It is important to have a space between the = sign and the list of dependencies. If you decide to unbind mrxsmb10 later, you just type in that line and leave the entry out of the list. Then, to set it up to auto start: sc.exe config mrxsmb10 start= auto To turn it back off: sc.exe config mrxsmb10 start= disabled If SMB 1.0 isn't on the machine (i.e.: the first line of code couldn't find the service), you may be able to find it in "Programs and Features" on the left side where it says "Turn Windows features on or off." In that list, you're looking for "SMB 1.0/CIFS," which would be unchecked, and you check it and restart. Windows should handle all the dependencies automatically when you do this. I don't think Windows 7 has that. In Windows 10 you have to explicitly install SMB 1.0/CIFS with "Turn Windows features on or off" or it isn't there. Start slow, and make sure you know how to back out of each step. The Workstation service won't start if it has the wrong dependencies. -- Zag No one ever said on their deathbed, 'Gee, I wish I had spent more time alone with my computer.' ~Dan(i) Bunten |
#4
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
On Tue, 31 Mar 2020 01:13:46 -0500, in alt.comp.os.windows-10, Zaghadka
wrote: On Tue, 31 Mar 2020 03:28:16 -0000 (UTC), in alt.comp.os.windows-10, Kenny McCormack wrote: Here's the situation. I have a Win7 machine that has been running fine for many years. It has a shared directory that is accessed on the home LAN by many clients - mostly Linux machines, but including one Windows XP box. This machine is up pretty much "all the time" and is rarely rebooted. The Win7 machine was rebooted 9 days ago. I think this is the triggering event, although the effects did not show up until today. Today, I found that older clients (the Linux boxes running older versions of Samba and the XP box) cannot connect to the Win7 share. I first noticed this by noting that existing connections had stopped working, and when I unmounted and attempted to remount, got error "Remote IO error" and the Samba mount failed. On XP (using "net use"), the error message is "The remote server cannot perform the requested operation". However, 3 of my Linux boxes continue to work fine with the share. They are all running up-to-date versions of Linux and Samba. Note, of course, that upgrading the older machines is not an option; if it were, I would just do that (and wouldn't be posting this). What I need to do is to fix the Win7 side so that it works as it did before. I know that Samba was recently "upgraded" to a new protocol for some "security" reason, such that sometimes you have to use "vers=1.0" on the client side to make it connect to older servers. This situation seems to be the "inverse" of that - i.e., the server is only accepting clients that speak the new protocol. What I think is going on is that the Win7 machine modified itself (probably as a result of the reboot) so that it no longer accepts version 1 client requests. What I need is to know what to tweak to change that back - so that it will work with the older clients as it did before. Anyone have any ideas? Serious replies only, please. I think I've tried all the "baby" things, like in the "Is it plugged in?" variety. First, try this on the Win 7 machine. sc.exe qc mrxsmb10 If the response is "The specified service does not exist as an installed service." then you don't have SMB 1.0 installed on your machine at all. If it's there, this line will bind SMB 1/2/3 to your Workstation service. sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi Any time you change depend= this way it overwrites the entire dependency tree. You can't append to it, you can only overwrite it. It is important to have a space between the = sign and the list of dependencies. If you decide to unbind mrxsmb10 later, you just type in that line and leave the entry out of the list. Then, to set it up to auto start: sc.exe config mrxsmb10 start= auto To turn it back off: sc.exe config mrxsmb10 start= disabled If SMB 1.0 isn't on the machine (i.e.: the first line of code couldn't find the service), you may be able to find it in "Programs and Features" on the left side where it says "Turn Windows features on or off." In that list, you're looking for "SMB 1.0/CIFS," which would be unchecked, and you check it and restart. Windows should handle all the dependencies automatically when you do this. I don't think Windows 7 has that. In Windows 10 you have to explicitly install SMB 1.0/CIFS with "Turn Windows features on or off" or it isn't there. Start slow, and make sure you know how to back out of each step. The Workstation service won't start if it has the wrong dependencies. You can also type: sc.exe qc lanmanworkstation and see if mrxsmb10 is in the dependencies list in the first place. If it isn't, sc.exe qc mrxsmb10 and see if SMB 1.0 is installed. If installed, use the depend= line above to add it. -- Zag No one ever said on their deathbed, 'Gee, I wish I had spent more time alone with my computer.' ~Dan(i) Bunten |
#5
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
In article ,
Zaghadka wrote: .... First, try this on the Win 7 machine. sc.exe qc mrxsmb10 If the response is "The specified service does not exist as an installed service." then you don't have SMB 1.0 installed on your machine at all. If it's there, this line will bind SMB 1/2/3 to your Workstation service. sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi Any time you change depend= this way it overwrites the entire dependency tree. You can't append to it, you can only overwrite it. It is important to have a space between the = sign and the list of dependencies. If you decide to unbind mrxsmb10 later, you just type in that line and leave the entry out of the list. Then, to set it up to auto start: sc.exe config mrxsmb10 start= auto To turn it back off: sc.exe config mrxsmb10 start= disabled If SMB 1.0 isn't on the machine (i.e.: the first line of code couldn't find the service), you may be able to find it in "Programs and Features" on the left side where it says "Turn Windows features on or off." In that list, you're looking for "SMB 1.0/CIFS," which would be unchecked, and you check it and restart. Windows should handle all the dependencies automatically when you do this. This all looks right. Thanks for posting. I have not gotten around to testing it yet - because of your warnings below - but I will eventually. What exactly can go wrong? Can you end up with a non-bootable machine? I don't think Windows 7 has that. In Windows 10 you have to explicitly install SMB 1.0/CIFS with "Turn Windows features on or off" or it isn't there. I looked into that ("Turn Windows features on or off") on the Win7 machine. There's a lot there, but nothing that seems to be related to SMB or Lan Manager. Start slow, and make sure you know how to back out of each step. The Workstation service won't start if it has the wrong dependencies. Can you tell me what can go wrong? How badly could I screw it up? And what, in particular, should I avoid doing? BTW, what exactly is "sc"? What does that stand for? (And, how did you learn all this? How did you learn about "sc"?) -- "Insisting on perfect safety is for people who don't have the balls to live in the real world." - Mary Shafer, NASA Ames Dryden - |
#6
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
On 3/30/2020 8:28 PM, Kenny McCormack wrote:
Here's the situation. I have a Win7 machine that has been running fine for many years. It has a shared directory that is accessed on the home LAN by many clients - mostly Linux machines, but including one Windows XP box. This machine is up pretty much "all the time" and is rarely rebooted. The Win7 machine was rebooted 9 days ago. I think this is the triggering event, although the effects did not show up until today. Today, I found that older clients (the Linux boxes running older versions of Samba and the XP box) cannot connect to the Win7 share. I first noticed this by noting that existing connections had stopped working, and when I unmounted and attempted to remount, got error "Remote IO error" and the Samba mount failed. On XP (using "net use"), the error message is "The remote server cannot perform the requested operation". However, 3 of my Linux boxes continue to work fine with the share. They are all running up-to-date versions of Linux and Samba. Note, of course, that upgrading the older machines is not an option; if it were, I would just do that (and wouldn't be posting this). What I need to do is to fix the Win7 side so that it works as it did before. I know that Samba was recently "upgraded" to a new protocol for some "security" reason, such that sometimes you have to use "vers=1.0" on the client side to make it connect to older servers. This situation seems to be the "inverse" of that - i.e., the server is only accepting clients that speak the new protocol. What I think is going on is that the Win7 machine modified itself (probably as a result of the reboot) so that it no longer accepts version 1 client requests. What I need is to know what to tweak to change that back - so that it will work with the older clients as it did before. Anyone have any ideas? Serious replies only, please. I think I've tried all the "baby" things, like in the "Is it plugged in?" variety. Check that you firewall on the server is operating properly. |
#7
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
In article , Bob F wrote:
.... Check that you firewall on the server is operating properly. That would be in the "Is it plugged in?" category. -- Trump has normalized hate. The media has normalized Trump. |
#8
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
On Thu, 2 Apr 2020 14:56:20 -0000 (UTC), in alt.comp.os.windows-10, Kenny
McCormack wrote: In article , Zaghadka wrote: ... First, try this on the Win 7 machine. sc.exe qc mrxsmb10 If the response is "The specified service does not exist as an installed service." then you don't have SMB 1.0 installed on your machine at all. If it's there, this line will bind SMB 1/2/3 to your Workstation service. sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi Any time you change depend= this way it overwrites the entire dependency tree. You can't append to it, you can only overwrite it. It is important to have a space between the = sign and the list of dependencies. If you decide to unbind mrxsmb10 later, you just type in that line and leave the entry out of the list. Then, to set it up to auto start: sc.exe config mrxsmb10 start= auto To turn it back off: sc.exe config mrxsmb10 start= disabled If SMB 1.0 isn't on the machine (i.e.: the first line of code couldn't find the service), you may be able to find it in "Programs and Features" on the left side where it says "Turn Windows features on or off." In that list, you're looking for "SMB 1.0/CIFS," which would be unchecked, and you check it and restart. Windows should handle all the dependencies automatically when you do this. This all looks right. Thanks for posting. I have not gotten around to testing it yet - because of your warnings below - but I will eventually. What exactly can go wrong? Can you end up with a non-bootable machine? I don't think Windows 7 has that. In Windows 10 you have to explicitly install SMB 1.0/CIFS with "Turn Windows features on or off" or it isn't there. I looked into that ("Turn Windows features on or off") on the Win7 machine. There's a lot there, but nothing that seems to be related to SMB or Lan Manager. Start slow, and make sure you know how to back out of each step. The Workstation service won't start if it has the wrong dependencies. Can you tell me what can go wrong? How badly could I screw it up? And what, in particular, should I avoid doing? BTW, what exactly is "sc"? What does that stand for? (And, how did you learn all this? How did you learn about "sc"?) [S]ervice [C]ontrol sc.exe is extremely powerful, and will let you screw up your system without warning you. In some cases, like when you're messing around with kernel drivers, which it also controls, that can mean a boot failure. Not for this application, though. What can go wrong in this case is you can make it so that the "Workstation" service won't start, which means no networking at all, and no way to fix it but by using sc to undo it the same way you broke it. So write everything down. To be sure you have an escape route, run first: sc.exe qc lanmanworkstation ....and make a note of what dependencies currently exist (bowser, mrxsmb##, nsi) so you can set them back to the original state if you suddenly find "Workstation" won't start. This is what mine looks like: SERVICE_NAME: lanmanworkstation TYPE : 20 WIN32_SHARE_PROCESS START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : C:\Windows\System32\svchost.exe -k NetworkService -p LOAD_ORDER_GROUP : NetworkProvider TAG : 0 DISPLAY_NAME : Workstation DEPENDENCIES : Bowser : MRxSmb20 : NSI SERVICE_START_NAME : NT AUTHORITY\NetworkService Note the three "dependencies." I don't load SMB 1.0, so it isn't on the list. (MRxSmb20 is *both* SMB 2 and 3.) When I learned all this, I managed to get myself into a place where "Workstation" wouldn't start, and what saved me was that I had good documentation. -- Zag No one ever said on their deathbed, 'Gee, I wish I had spent more time alone with my computer.' ~Dan(i) Bunten |
#9
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
On 4/2/2020 9:07 AM, Kenny McCormack wrote:
In article , Bob F wrote: ... Check that you firewall on the server is operating properly. That would be in the "Is it plugged in?" category. I've had a couple cases where Norton would "go away". Then my other PCs could not access the files on it. Never did figure out why it went away. |
#10
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
In article , Bob F wrote:
On 4/2/2020 9:07 AM, Kenny McCormack wrote: In article , Bob F wrote: ... Check that you firewall on the server is operating properly. That would be in the "Is it plugged in?" category. I've had a couple cases where Norton would "go away". Then my other PCs could not access the files on it. Never did figure out why it went away. Norton who? -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/ForFoxViewers |
#11
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMB clients
In article ,
Zaghadka wrote: .... [S]ervice [C]ontrol sc.exe is extremely powerful, and will let you screw up your system without warning you. In some cases, like when you're messing around with kernel drivers, which it also controls, that can mean a boot failure. Not for this application, though. What can go wrong in this case is you can make it so that the "Workstation" service won't start, which means no networking at all, and no way to fix it but by using sc to undo it the same way you broke it. So write everything down. To be sure you have an escape route, run first: sc.exe qc lanmanworkstation ...and make a note of what dependencies currently exist (bowser, mrxsmb##, nsi) so you can set them back to the original state if you suddenly find "Workstation" won't start. A late followup on this: I never did get around to testing any of this (your fine advice). Nevertheless, I am grateful for your help; it may yet come in handy some day. But I was a little freaked out by the dire warnings; I cannot afford to lose this machine. Any interruption in service would be a distinct hardship. Anyway, given that the problem manifested after a reboot, it had always been my suspicion that the problem would go away on the next reboot - essentially to go away as mysteriously as it arrived. And, indeed, that is the case. We finally got around to rebooting the machine in question today, and the problem is no more. Don't you just love Windows and its randomness? That's what we love about Windows - how so often a reboot fixes anything/everything. Footnote: I can imagine that this whole thread might seem weird to some people - people used to Windows - who just assume that the first thing you try on *ANY* Windows problem is rebooting. So, they would say, of *COURSE* you tried rebooting before you even thought about posting to an online forum seeking help, right? Well, as you can see, in this instance, that is not the case. This machine is very infrequently rebooted. Furthermore, I'm on a kick these days of trying to find solutions to problems that *DON'T* involve rebooting. That is, to *NOT* have rebooting be the first resort. It should, in a production setting, be the last resort. Anyway, here's hoping the problem does not re-appear... -- Atheism: It's like being the only sober person in the car, and nobody will let you drive. |
#12
|
|||
|
|||
Can no longer connect to Windows Share (Win7) with older SMBclients
Kenny McCormack wrote:
In article , Zaghadka wrote: ... [S]ervice [C]ontrol sc.exe is extremely powerful, and will let you screw up your system without warning you. In some cases, like when you're messing around with kernel drivers, which it also controls, that can mean a boot failure. Not for this application, though. What can go wrong in this case is you can make it so that the "Workstation" service won't start, which means no networking at all, and no way to fix it but by using sc to undo it the same way you broke it. So write everything down. To be sure you have an escape route, run first: sc.exe qc lanmanworkstation ...and make a note of what dependencies currently exist (bowser, mrxsmb##, nsi) so you can set them back to the original state if you suddenly find "Workstation" won't start. A late followup on this: I never did get around to testing any of this (your fine advice). Nevertheless, I am grateful for your help; it may yet come in handy some day. But I was a little freaked out by the dire warnings; I cannot afford to lose this machine. Any interruption in service would be a distinct hardship. Anyway, given that the problem manifested after a reboot, it had always been my suspicion that the problem would go away on the next reboot - essentially to go away as mysteriously as it arrived. And, indeed, that is the case. We finally got around to rebooting the machine in question today, and the problem is no more. Don't you just love Windows and its randomness? That's what we love about Windows - how so often a reboot fixes anything/everything. Footnote: I can imagine that this whole thread might seem weird to some people - people used to Windows - who just assume that the first thing you try on *ANY* Windows problem is rebooting. So, they would say, of *COURSE* you tried rebooting before you even thought about posting to an online forum seeking help, right? Well, as you can see, in this instance, that is not the case. This machine is very infrequently rebooted. Furthermore, I'm on a kick these days of trying to find solutions to problems that *DON'T* involve rebooting. That is, to *NOT* have rebooting be the first resort. It should, in a production setting, be the last resort. Anyway, here's hoping the problem does not re-appear... One of the relatively "new" features during Windows Update installations, is Microsoft does the first reboot after the update with a separate user profile. For some reason, they don't want to use (or upset) the normal users profile. When the machine is rebooted again moments later, it's supposed to switch back to the normal user profile (what you log in with). When it does that, what's supposed to happen, is two series of juggling balls, followed by the second reboot (you are not supposed to have an opportunity to intervene). If for some reason, this choreographed dance fails, then you might end up on the (empty, temporary) profile. The other style of bug, is where some service gets killed during an installation, and the machine doesn't seem to behave quite right later on. This might be an install which doesn't reboot right away. While you can "reboot for luck", there are a couple scenarios more familiar to Windows 10 which could use a "logical reboot" a "reboot for a guessed reason". Paul |
Thread Tools | |
Display Modes | Rate This Thread |
|
|