NAS via \\Servernaam\Share niet meer te bereiken

[spinningmaster]

Hoi allemaal,

Sinds een aantal dagen zit ik met een merkwaardig, maar irritant probleem.

Mijn NAS is niet meer benaderbaar via mijn netwerkmappen (\\Servernaam\Share) op mijn PC.
Dit gebeurd bij het gebruik van Firefox en Windows Verkenner
Als ik het ip-adres in Firefox of een andere browser intoets, kom ik gewoon bij het inlogscherm van mijn NAS en na het ingeven van user en wachtwoord kom ik op mijn NAS.

Er is op mijn PC (Windows 10) bij mijn weten niets veranderd.
Heb sinds een maand wel een abonnement bij een VPN provider (ExpressVPN), maar dit is volgens mij niet de oorzaak omdat het altijd heeft gewerkt incl. de VPN verbinding.
Heb mijn VPN verbinding verbroken maar ook dan krijg ik geen verbinding met mijn NAS via een netwerkmap.

Ook geprobeerd om een nieuwe netwerkverbinding te maken maar dat lukt niet omdat de NAS niet wordt gevonden.
Heb de laatste firmware versie van de NAS geïnstalleerd maar helaas geen resultaat.

Ook geprobeerd een herstelpunt in Windows terug te zetten maar uiteindelijk mislukte dit omdat mijn virusscanner actief was.
Het vreemde was dat daarna het wel weer werkte, maar na het uitzetten van mijn PC en deze een dag later weer aan te zetten kon ik opnieuw de mappen op mijn NAS niet benaderen.

Gebruik op mijn PC een User die Admin rechten heeft op mijn NAS, dus ik zou gewoon de  shares met \\Servernaam\Share moeten kunnen benaderen, zoals dat altijd heeft gewerkt.

Aangezien ik veel via de netwerkshare werk, zou ik het probleem willen repareren.
Heeft iemand van jullie een idee hoe?

[pvkan]

Eerst maar eens kijken of je PC de NASnaam nog kan vinden:

Wat gebeurd er als je ipv \\Servernaam\Share
\\ip-nummer NAS\Share gebruikt?

Peter

[Plerry]

Even aannemende dat je thuis geen domein hebt en geen eigen DNS server,
komt het resolven van de netwerknamen aan op NetBIOS en welk apparaat
binnen je subnet (en werkgroep?) de rol van Master Browser aanneemt.

De werking als Master Browser van een Windows system blijkt al vele jaren
zeer krakkemikkig en wordt al vele jaren lang ook niet door MS opgelost.   

De simpelste oplossing is om IP-adressen te gebruiken in plaats van netwerknamen.
Uiteraard moet je het IP-adres van je shared netwerkresources (NAS, printer, ...)
dan wel vast ingesteld hebben of vast door je DHCP server laten toewijzen (DHCP reservation).

Wil je niettemin als een Don Quichot het gevecht tegen de windmolens aangaan  ,
prober dan te zorgen dat een ander apparaat dan een Windows machine de rol van
Master Browser vervult, bijvoorbeeld je NAS.
Stel in DSM je NAS zo in dat deze de rol van Local Master Browser kan vervullen.
Je vindt dat onder: DSM/ControlPanel/FileServices/WindowsFileServices/AdvancedSettings/EnableLocalMasterBrowser

In principe neemt het eerste apparaat dat aanstaat en de rol van Local Master Browser kan aannemen die rol ook aan.
Zet dus alle verbonden apparaten uit (PC's, mediaspelers, zo goed als alles ... ) en alleen je NAS aan.
Laat dat circa 15 minuten zo staan, en schakel dan de andere apparatuur weer in (zover nodig).
Als het goed is, is nu je NAS de Local Master Browser en blijft dat.
Zeer instructief: de reply van bab1 in deze discussie.
Moet je je NAS herstarten, dan moet je bovengenoemde procedure opnieuw door, anders heeft ondertussen een ander device
de rol van Local Master Browser overgenomen ... 

[spinningmaster]

Wat gebeurd er als je ipv \\Servernaam\Share
\\ip-nummer NAS\Share gebruikt?

Allereerst bedankt voor de reactie pvkan. 
Zal dat vanavond gaan proberen en laat dan weten wat het als resultaat heeft opgeleverd.

[spinningmaster]

Stel in DSM je NAS zo in dat deze de rol van Local Master Browser kan vervullen.
Je vindt dat onder: DSM/ControlPanel/FileServices/WindowsFileServices/AdvancedSettings/EnableLocalMasterBrowser
Moet je je NAS herstarten, dan moet je bovengenoemde procedure opnieuw door, anders heft ondertussen een ander device
de rol van Local Master Browser overgenomen ... 

Bedankt voor je reactie Plerry.
Dit gaat niet lekker voor mij werken omdat de NAS aangaat als ik hem nodig heb, dit is wel dagelijks.
Het vreemde is dat dit jaren lang zonder problemen heeft gewerkt en van de ene dag op de andere niet meer.
Al mijn apparaten hebben een DHCP reservation via de router.

Ga wel vanavond IP-adressen gebruiken i.p.v. van netwerknamen.
Kom er vanavond op terug.

[pvkan]

Mocht het met IPnummer wel werken dat kan je de vertaling IP naar servernaam altijd
nog opnemen in je Windows 'hosts' bestand (dan wel op elke PC apart).

Peter

[spinningmaster]

@pvkan bedankt voor de tip.
Het veranderen van de servernaam in het IP-adres heeft gewerkt helemaal top.

Zou je mij een voorbeeld kunnen geven van de aanpassing in het Windows 'hosts' bestand.
Heb maar 1 pc dus erg veel moeite om het aan te passen is het niet.

Nogmaals dank voor de tip.

[Briolet]

Googelen op "hosts bestand" helpt. Dit werkt voor windows/linux/Mac. Alleen de locatie van het bestand verschilt.

[Birdy]

Windows C:\Windows\System32\drivers\etc\hosts

# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

# localhost name resolution is handled within DNS itself.
#   127.0.0.1       localhost
#   ::1             localhost
192.168.1.20   DS411-ii
192.168.1.21   DS413j
192.168.1.22   DS111
192.168.1.23   DS716II
192.168.1.24   DS411Slim

[m4v3r1ck]

^^^^ Bedankt! Ik was er ook naar op zoek.

 

[pvkan]

@spinningmaster

Ik zie dat men mij al voor is geweest met de uitleg en lokatie van het hosts bestand in Windows ;-)

Peter

[spinningmaster]

@Birdy,

Bedankt voor de uiteenzetting 

[Hofstede]

@m4v3r1ck: Met jouw USG heb je dat niet nodig. 

Al jouw netwerkapparaten worden automatisch toegevoegd in de hosts file van de USG en zijn dan via <hostnaam>.<domeinnaam> bereikbaar.

De <domeinnaam> kun je in je netwerkdefinitie van de controller opgeven. Default is localdomain.

[m4v3r1ck]

^^^^ Bedankt! Ik heb in mijn netwerken .local en guest.local aangemaakt. In mijn VMware Fusion Windows 10, kon ik mijn NAS ook niet meer benaderen, ondanks de instellingen ervoor in credential manager. Door het aanpassen van de hosts-file kan ik nu wel mijn NAS benaderen.

 

[tarzanhond]

Windows 10 en de toegang tot een linux samba bestandsserver.
Samba is de linux implementatie van het windows bestandsdelingsprotocol. Samba is open source software en dus gratis in het gebruik. Het is gebleken dat de toegang tot een samba bestandsserver in de meeste gevallen met een windows 10 PC niet meer functioneert. De reden hiervan is dat Microsoft de beveiliging van bestandstoegang vanuit een windows 10 client aanzienlijk heeft aangescherpt. Beveiliging is uiteraard noodzakelijk en zeer belangrijk, echter beveiliging kan al snel een probleem gaan vormen wanneer een eigen server op uw lokale netwerk door een Windows 10 PC in uw bedrijfsnetwerk niet meer wordt “vertrouwd”. Met name wanneer er zich hierop uw belangrijke documenten en bestanden bevinden waarmee gewerkt moet kunnen worden. Enig googlen levert al snel een mogelijke oplossing nummer één op, namelijk door in de registry editor de parameter HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\AllowInsecureGuestAuth aan te maken en deze de waarde 1 te geven. Bij testen blijkt echter in de praktijk dat dit niet helpt. Potentiële oplossing nummer twee zou zijn om via configuratiescherm -> referentiebeheer een referentie aan te maken naar de samba bestandsserver en de gebruikersnaam/wachtwoord hierbij op te slaan. Dit kan middels een hostnaam of een IP Adres waarmee naar de samba server wordt gerefereerd. Wederom bleek bij testen dat dit in veel gevallen niet werkt.
Er is zeker iets vreemds en meer specifieks aan de hand betreffende dit probleem. Wat onder andere te lezen valt in samba userlists, is dat Windows 10 bij toegang tot een linux bestandsserver het zeer nieuwe SMB3_11 protocol onderhandelt hetgeen momenteel bij de meeste samba servers niet goed gaat. Er is echter meer aan de hand want bij het koppelen van een gedeelde map op een Windows XP PC is er geen enkel probleem om dit vanuit Windows 10 te doen. Hierbij weten we zeker dat XP het SMB3_11 protocol niet heeft aangeboden omdat dit te nieuw is. Toch verloopt de onderhandeling tussen windows 10 client en Windows XP PC vreemd genoeg wel met succes. Linux samba shares worden dus blijkbaar anders beschouwd door Windows 10 dan windows SMB shares. Hoe dit verschil ontstaat is op dit moment nog niet helemaal duidelijk.
Er is er al wel een methode om het probleem te verhelpen, hoewel deze methode niet bijzonder elegant te noemen valt. Wat is gebleken, is dat bij uitschakelen van het SMB3 protocol op de windows 10 client PC het koppelen van de samba share wel lukt. Hierna zijn samba shares wel toegankelijk.
Uitschakelen van het SMB 2/3 protocol op een Windows 10 client PC gaat op de volgende wijze:
In een CMD scherm met administrator bevoegdheden uitvoeren:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled
Hierna de PC herstarten.
Weer inschakelen gaat middels de volgende commando’s:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc.exe config mrxsmb20 start= auto
Hierna wederom de PC herstarten.