Sharing trouble

Two machines, A and B. I want to share a folder that resides
on each of them. The machines are both Win 10 pro 1909. They
are configured identically; both are hooked to an Enet switch.
For this exercise, I have no AV running on either, just Defender.

I went through the same steps on each to share a folder and
think I've found all the Windows settings necessary. Now,
A can see B in File Explorer on A, but B can't see anything on A.
The Windows troubleshooter doesn't find anything suspicious on
either machine.

Where should I look now?

On 2/17/2020 7:49 PM, Jason wrote:
Two machines, A and B. I want to share a folder that resides
on each of them. The machines are both Win 10 pro 1909. They
are configured identically; both are hooked to an Enet switch.
For this exercise, I have no AV running on either, just Defender.

I went through the same steps on each to share a folder and
think I've found all the Windows settings necessary. Now,
A can see B in File Explorer on A, but B can't see anything on A.
The Windows troubleshooter doesn't find anything suspicious on
either machine.

Where should I look now?

Make sure that the owner of the folder is the person who is sharing the
folder.

If the account you are log into belongs to John, and John has been given
access to the folder by Pete the owner of the folder, then Pete is the
only one who can share the folder.

If this is the case you may have to change the ownership of he folder.

Jason wrote:
Two machines, A and B. I want to share a folder that resides
on each of them. The machines are both Win 10 pro 1909. They
are configured identically; both are hooked to an Enet switch.
For this exercise, I have no AV running on either, just Defender.

I went through the same steps on each to share a folder and
think I've found all the Windows settings necessary. Now,
A can see B in File Explorer on A, but B can't see anything on A.
The Windows troubleshooter doesn't find anything suspicious on
either machine.

Where should I look now?


Are you one of the BlackViper folks ? Those
are people who "remove services that don't look
all that helpful". Then, later, they're surprised when
stuff is broken.

When HomeGroups disappeared, initially there might have been
a suggestion to switch off a bunch of stuff. It turns out
that would be bad advice.

Note that, a couple of services beginning with "f"
from the HomeGroups era, are still necessary. You can't
switch them off. fdrp and fdph in services.msc. It might
take a total of seven services to make sharing work. I couldn't
find a handy list using fdrp and fdph to bootstrap myself.

And in your testing, you likely neglected to test with
IP addresses. It's all part of test procedures.

smb://192.168.1.2/project14 # Linux (I use numeric addresses)

smb://bob/project14 # Linux

\\192.168.1.2\project14 # Windows (since I've memorized the addresses...)

\\bob\project14 # Windows (try typing the name of the machine itself)

In the second examples, you're relying on a nameserver thing
running amongst the machines, to register names and keep
track of their IP addresses. The nameserver converts a request
for "bob" into "192.168.1.2" as long as the name service is
running properly everywhere.

Nameserving has been broken on Linux for a while. I suppose
in the same sense as they break FTPD or TELNETD, passing on
paternalistic ideas of "who controls the software you use".
That's why I use a lot of numeric addresses, rather than "bob".

In the first example, you are skipping the convenience of
using "bob" for naming and are getting right to the crux of the matter.

On the Bob machine, I would run cmd.exe and do

ipconfig

and it dumps out IPV4 or IPV6 addresses. These could be
dynamically assigned via DHCP on your home router, or
statically assigned by editing the network panel for
the NIC, locally on each Windows setup. You can also
mix the two concepts (static address usage OK, as long
as it falls outside the router DHCP from-to address range).

*******

If you are running any WinXP or Win2K machines, you can go
to Windows 10 "Programs and Features" control panel and
see the "Windows Features" section and turn on two of the
three SMBV1 options. The SMBV1 is turned off by default as
some sort of "security thing". One of the items in the list,
turns the service off if it isn't used for a while, and you
don't want to be ticking that one.

Windows has SMBV1, SMBV2, SMBV3, which are only slightly
different from one another. The crypto on SMBV1 is likely
weak as ****. On Windows 10 there is a Powershell command
which can give details for a "successful" network connection,
but I haven't located anything which records failures. I tried
using Wireshark to debug a failed network session, but the
"dissector" in Wireshark doesn't decode the reason register,
which means you can't actually use the tool to dissect anything.
It would still require schoolwork to decode what is going on.

My bug, in particular, said "More info needed" as the status
coming back from the disgruntled node. What the hell good is
"More info needed" as an error ? Surely the failing bit could
say "Don't like the name", "Don't like the IP", "No matching crypto"
or something equally descriptive. At least it didn't send
a "Something Happened" error :-/

*******

http://www.unixwiz.net/tools/nbtscan.html

On the Windows machine, you can try

nbtscan.exe 192.168.3.0/24 # Scan 256 addresses on 3

192.168.3.104 WORKGROUP\BOB SHARING
192.168.3.109 WORKGROUP\ZBOX SHARING
*timeout (normal end of scan)

Both of the machines located, are using workgroup=WORKGROUP.
The scan can detect machines in different workgroups, useful for
identifying machines that need their workgroup value updated.

In that particular example, 109 was a virtual machine, and 104 was
the address of the host machine. I simulated that with only
the one computer running.

If you wanted to scan even more nodes, you could try

nbtscan.exe 192.168.0.0/16 # Scan 64K addresses or so

but that would take a while. You should only scan the addresses
that reasonably exist on your setup.

*******

Sometimes the reason for the failure in one direction,
is how your routing is set up. And what is upstream of
some other thing. For me, networking works best, if all the
nodes are off the same dumb switch. That causes less
hairloss for me. Some of my kit is "unreachable" but
I'm OK with that, and nothing important sits on the "unreachable" part.

WAN ------- router1 ----------- router2 -----------
192.168.3.1 192.168.2.1
\ \
timmy wally

Can Timmy see Wally ? I haven't a clue :-)

I like setups like this. One less thing to worry about.
I should see four nodes in the Network window, if one exists.

WAN -------- router -------- Able
-------- Baker
-------- Charlie
-------- Foxtrot

HTH,
Paul

In article ,
says...
If this is the case you may have to change the ownership of he folder.


Thanks. I'll check that. As I said, I'm stumped. Since I am the only
user of both machines, it's likely that ownership is not the issue,
but then again...it's Windows! Who knows if something may have changed.

On 2/19/2020 11:52 AM, Jason wrote:
In article ,
says...
If this is the case you may have to change the ownership of he folder.


Thanks. I'll check that. As I said, I'm stumped. Since I am the only
user of both machines, it's likely that ownership is not the issue,
but then again...it's Windows! Who knows if something may have changed.

I don't know about your machine but on mine there are several accounts;
Administration, System, Everyone, User, etc. There are some time some
accounts that are identified with a string of numbers. (So far I have
been able to successfully delete these.) To get the share to work all of
the shared items had to be in the same account ie Administration

In article ,
says...
To get the share to work all of
the shared items had to be in the same account ie Administration

I understand the ownership angle. Trouble is, the new machine is
a near clone of the old one - same accounts and all - so ownership
should match on both ends of the connection.