Question Why Windows loses track of Synology NAS

[Telos]

In the Community, there are countless posts complaining of the inability to see the NAS in Windows Explorer... My experience points to something murky with DSM (or my own ignorance... who knows?).

Here's what I see presently.

Dbl-clicking the NAS icon displays a window with all Shared Folders... as it should. But after a few days, the NAS icon is no longer present in this view. I can make it reappear toggling "WS-Discovery" off and on (disable/apply/enable/apply).

What I can't figure is why I need to do that? Does toggling this setting put the NAS into action, or my laptop (the icon appears within seconds of enabling WS-Discovery).

To work around this nuisance I've "pinned" the NAS to File Explorer, however, I'd much prefer to click the icon (show) without scrolling to find the pinned NAS.

Any ideas on why the NAS (SMB) stops appearing under File Explorer's "Computer" section.

 

[AzureMurph]

There are numerous reasons why that can happen.

My first query is, why are you depending on network discovery and not mapping it as a network location?

Is that due to DNS/DHCP changes/credential mapping?

 

[AzureMurph]

How I tend to work with using DSM within Windows is as follows.

Get the MAC address of the network interface for the DSM, can get confusing if you have 2 nics. If you are using both just make a note of both MAC addresses.
To do that login to your DSM web gui.
Control Panel/Connectivity/Network/Network Interface/LAN 1, hit the drop down arrow to get the details. You can copy and paste the MAC from there. Make a note of the IP it currently has.

Login to your router. Admin details usually on a sticker.

Depending on your router and broadband provider, the menu/instructions will be slightly different.
However, your router will normally be the DHCP server for your home network. Find the settings for the DHCP server and reserve the IP address that your DSM has, using the MAC address.
That way it will always be given the same IP. You now have a static IP internal/private IP address.

Next step is to create a user account and assign it user access, and read/write access to the file shares/folder shares on the NAS.

Create | DSM - Synology Knowledge Center

Synology Knowledge Center offers comprehensive support, providing answers to frequently asked questions, troubleshooting steps, software tutorials, and all the technical documentation you may need.

www.synology.com

Assign Shared Folder Permissions | DSM - Synology Knowledge Center

Synology Knowledge Center offers comprehensive support, providing answers to frequently asked questions, troubleshooting steps, software tutorials, and all the technical documentation you may need.

www.synology.com

Within windows go start menu/control panel and search for credential manager.

https://support.microsoft.com/en-us/help/4026814/windows-accessing-credential-manager

Select windows credentials, add a windows credential.
For the address enter
\\yourstaticinternalipaddress
So what ever address you just reserved, use that. for example \\10.0.0.10
For the username, you will need to enter the name you have given your dsm.
Details on how to do that can be found here

General | DSM - Synology Knowledge Center

Synology Knowledge Center offers comprehensive support, providing answers to frequently asked questions, troubleshooting steps, software tutorials, and all the technical documentation you may need.

www.synology.com

For this example, lets say its named diskstation

so username will be

diskstation\usernameyoucreatedealier
password will be the password for the user.

click ok, save . etc

reboot your machine

Once logged back in, open file explorer, click map network drive.
Enter \\10.0.0.10 and the hit browse, you won't need to enter credentials, select the file share you want to map and give it a drive letter. Select reconnect a sign in, but don't tick user other credentials as you don't need to.

https://support.microsoft.com/en-gb/help/4026635/windows-map-a-network-drive

 

[Telos]

My first query is, why are you depending on network discovery and not mapping it as a network location?

Thanks for your input. I need access to multiple shares, so mapping is not productive. Presently I use a combination of pinning and a desktop shortcut to the NAS. I've also cleaned up Windows credentials, without any persistent effect.

My goal is to "see" the NAS in Window's Explorer's Network view (shown under "Computer").

It seems odd that toggling WS-Discovery from on-to-off-to-one fixes things. However, I ran across a post that suggested a programming error in the Synology python ws-discovery scripts was suspect. So I located the responsible script (it was different between my machines) and edited the appropriate script. So far, and it's too early to say with any authority, both NAS are still present, and accessible, under Window's Network view as"Computer".

 

[Shadow]

imo relying on broadcast to use services (like file services) is very unreliable... I don't understand why people are making such a point about this..

Map drives, or use the Drive app.

 

[jeyare]

better and faster way how to define the static IP address for the NAS NIC (or for Bond) you can do it directly in the DSM Control panel. No need to copy and paste MAC address/es from NAS to router, then back,.....
Also Disk mapping is useful:
- you don’t need map every single Shared folder in your NAS (up to your architecture)
- everything is connected
- when you have a troubles with the mapping or the credential to already mapped drive, use my guide
Also there is possible (frequently) incorrect setup of SMB at NAS or WIN side.

Save your time for a joy!

 

[Shadow]

better and faster way how to define the static IP address for the NAS NIC (or for Bond) you can do it directly in the DSM Control panel. No need to copy and paste MAC address/es from NAS to router, then back,.....

I don't agree this is a better way. You will no longer have IP addresses managed from a single point.

 

[jeyare]

I don't agree this is a better way. You will no longer have IP addresses managed from a single point.

up to your network management approach

mine is running with such approach in years:
- fixed range defined for fixed setup at client side for all managed VLANs (all of my known devices, incl. smartphones). Then don't need to define at router side more than this "basic/advanced" setup (except Radius server and MAC addresses check).
- fixed range defined for rest of DHCP part of the subnet/s (for devices, where I don't expect a remote management), in my case it's just two devices in single VLAN
- fixed range for Guest DHCP part of the VLAN subnet (here I don't need management of the guest devices, just cut them from the Hotspot portal App)

then answer is - yes - it's applicable. But you need clear strategy, how to do it (almost better).
Ordnung muss sein

 

[Telos]

It seems odd that toggling WS-Discovery from on-to-off-to-one fixes things. However, I ran across a post that suggested a programming error in the Synology python ws-discovery scripts was suspect. So I located the responsible script (it was different between my machines) and edited the appropriate script.

I wanted to follow-up on this... The script edit has continued to work without interruption...until I updated DSM (which so kindly returned the script to its broken status). For the more daring among you here, I'll share this simple edit. [Note: This is based entirely on a post I stumbled across in the Community.]

I located the offending script in different files on different NAS...
/usr/lib/python2.7/site-packages/WSDiscovery.py, near line 955
/usr/lib/python2.7/site-packages/wsdiscovery/daemon.py, near line 177

Original code:

for fd, event in self._poll.poll(timeout):
            sock = socket.fromfd(fd, socket.AF_INET, socket.SOCK_DGRAM)
            try:
                data, addr = sock.recvfrom(BUFFER_SIZE)
            except socket.error as e:
                time.sleep(0.01)
                continue

Modified code:

for fd, event in self._poll.poll(timeout):
            try:
                sock = socket.fromfd(fd, socket.AF_INET, socket.SOCK_DGRAM)

                data, addr = sock.recvfrom(BUFFER_SIZE)
            except socket.error as e:
                time.sleep(0.01)
                continue

Before editing the script file, I unchecked WS-Discovery in Control Panel. After editing I returned it back to it's checked state. FWIW, it's a good practice to make a copy of the original script file before editing.

I hope this helps someone. Unfortunately, the re-edit is required with a DSM update.

 

[Micky]

So why does Synology not update this script and release it to public?

 

[Telos]

So why does Synology not update this script and release it to public?

Begin reading here and through the following 2 posts by Bernard Hasch.

 

[Telos]

I located the offending script in different files on different NAS...
/usr/lib/python2.7/site-packages/WSDiscovery.py, near line 955
/usr/lib/python2.7/site-packages/wsdiscovery/daemon.py, near line 177

It appears that DSM v6.2.3 has introduced changes to the WS-Discovery file structure, moving the coding issue to daemon.py.

 

[AzureMurph]

up to your network management approach

mine is running with such approach in years:
- fixed range defined for fixed setup at client side for all managed VLANs (all of my known devices, incl. smartphones). Then don't need to define at router side more than this "basic/advanced" setup (except Radius server and MAC addresses check).
- fixed range defined for rest of DHCP part of the subnet/s (for devices, where I don't expect a remote management), in my case it's just two devices in single VLAN
- fixed range for Guest DHCP part of the VLAN subnet (here I don't need management of the guest devices, just cut them from the Hotspot portal App)

then answer is - yes - it's applicable. But you need clear strategy, how to do it (almost better).
Ordnung muss sein

So managing DHCP scopes from the client side, and not from the DHCP server, IE the router?

 

[AzureMurph]

Thanks for your input. I need access to multiple shares, so mapping is not productive. Presently I use a combination of pinning and a desktop shortcut to the NAS. I've also cleaned up Windows credentials, without any persistent effect.

My goal is to "see" the NAS in Window's Explorer's Network view (shown under "Computer").

It seems odd that toggling WS-Discovery from on-to-off-to-one fixes things. However, I ran across a post that suggested a programming error in the Synology python ws-discovery scripts was suspect. So I located the responsible script (it was different between my machines) and edited the appropriate script. So far, and it's too early to say with any authority, both NAS are still present, and accessible, under Window's Network view as"Computer".

Do you just want it to appear in the file explorer navigation pane, so you can expand it from the top level and see al shared folders? A bit like this?

192.168.0.14 is the internal IP of the DSM.

Have found two ways to achieve this so far, setup FTP and lock it down to your internal network, then assign the relevant permissions, and add the account with the permission into credential manager and then map as a network location.

Or set up SMB/NFS shares (your preference), make sure you install the relevant windows features.

The FTP and SMB share are now both displayed and expandable within windows file explorer navigation pane, from the top level of the permissions assigned to the account you have added into credential manager.

 

[Telos]

SMB1 is deprecated. Usage not recommended.

 

[AzureMurph]

SMB1 is deprecated. Usage not recommended.

Agreed, I didn’t recommend it, just providing options that work. Go with ftp, can easily be secured and locked down.

 

[Telos]

Thanks. As I posted above, the tweak to Synology's WS Discovery script has stabilized the appearance of the NAS under "Networks" in Win10. This suggests a fault within Synology's script.

 

[jeyare]

So managing DHCP scopes from the client side, and not from the DHCP server, IE the router?

No, this is wrong understanding of my wording. Typing of network setup details in client side (NIC) is too far from the network management. It's about a keeping of network rules (definitions, security). For the clean a secure network operation.

As you can see in my description, everything is managed from single point, in my case from Ubiquiti Unifi controller.
Before I started using the Unifi, everything was managed by Cisco router - again single point of management (but really different = worse and not such convenient as in Unifi). That's mean = from the network management "server" side. Because I have disabled DHCP feature for all of VLANs except two of them (physically isolated guest network, smart devices network) I have better sleeping.

My post was kind of reaction for @Shadow post "You will no longer have IP addresses managed from a single point."

But I do that many years

 

[jeyare]

as was posted many times, for the network discovery in Win OS part of the world you can use useful tool called Advanced IP Scanner (many features), it can show you more than you expect

 

[AzureMurph]

Thanks. As I posted above, the tweak to Synology's WS Discovery script has stabilized the appearance of the NAS under "Networks" in Win10. This suggests a fault within Synology's script.

What settings do you have switched on within Windows features? Which services are enabled within the NAS?
Have updated the script, but no joy as yet.
I didn't even particularly want this functionality, but you have me intrigued.

Also is VI the only editor available when connected by SSH?