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.

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.

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

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

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 -

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.

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.

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

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.

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

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.

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