Plotseling zijn shares niet meer benaderbaar in Win10

[mopringles]

Ik heb een NAS met daarop meerdere shares. Deze heb ik gemapt als x:, y: z: Een Windowslaptop met de meest recente update kan dit apparaat van het ene moment op het andere niet meer benaderen via de verkenner. Wanneer ik deze via net use koppel mbv Powershell, kan ik ze daar wel uitlezen, maar verder ziet Windows deze niet. Een andere Windowslaptop kan dit wel, evenals mijn Androidtelefoon, Linuxcomputer en Apples. Aan de NAS ligt het dus niet.
Andere shares op andere apparaten leveren geen problemen op.
...

Windows 10 versie 2004, Netgear Duo (niet te benaderen), Rasperry Pi met OSMC, vier shares, wel te benaderen. Cyberghost VPN (uit en aangezet), Windows firewall uit en aangezet.
...

Ik kan even niet bedenken wat hier aan de hand is.

[Wim-Bart]

Toevallig SMB 1.0 feature uit staan in Windows?

[Krypt]

Heb je überhaupt ooit een username/wachtwoord combi in moeten geven?
Als dat niet zo is, dan heb je eindelijk een update te pakken die anonymous login tegen gaat.

Doe je de net use in powershell met username en wachtwoord? Als het een elevated powershell is, heb je de kans dat ie in andere context draait en in je "user" context je de mappings niet ziet.
Met cmdkey kun je credentials opslaan voor bijv. Shares.

Edit:
Anonymous login Windows 10 SMB 2.0 is per December 2019 disabled met een update.

https://support.microsoft...indows-10-and-windows-ser

[ Voor 19% gewijzigd door Krypt op 24-06-2020 19:52 ]

[mopringles]

Ja, username en wachtwoord enabled, dus geen anonymous login. Wanneer ik met net use map, moet ik die ook ingeven en gaat het goed. Dan kan ik de share ook benaderen vanaf de command line. Maar niet via bijvoorbeeld de verkenner.

[mopringles]

smb 1.0 had ik aanstaan ivm een eerdere akkefietje. Maar ik check even of die nog aanstaat.

[mopringles]

Ai, te snel op verzend gedrukt. SMB1.0 stond nog aan en opnieuw activeren was geen oplossing.

[Blokker_1999]

Je zegt je kan ze vanuit de verkenner niet benaderen. Welke boodschap krijg je juist? Probeerd hij deze te openen en blijft alles leeg of is er meer aan de hand? Wat gebeurd er als je in de adresbalk van de verkenner het UNC pad ingeeft naar de share? En als dat laatste wel werkt, heb je de mapping al eens opnieuw aangemaakt?

Wanneer je via de command line gaat, wat doe je dan net, koppel je de schijven opnieuw aan een letter om deze dan te benaderen? Kan je deze dan ook vanuit de verkenner benaderen?

Oh, en indien niet absoluut noodzakelijk, SMB1 uitzetten op je Windows machines.

[ Voor 7% gewijzigd door Blokker_1999 op 24-06-2020 20:06 ]

[mopringles]

Ha, weer een stapje verder. Wanneer ik in het UNC-pad de servernaam ingeef, ziet hij de server niet. Wanneer ik de naam vervang door het IP-adres kan ik er weer gewoon bij. Waarom dit op de ene laptop niet meer gaat en op de andere nog wel, ontgaat me nog even.

Helaas SMB1 nog wel nodig voor een heel oud apparaatje dat ik niet meer kan updaten, of laat ik zo zeggen, waarbij ik strandde bij mijn laatste pogingen.

Nee, het gekke was dus dat als ik naar de command line ga, de schijven niet via de verkenner te benaderen waren, alleen via de command line.

[mopringles]

Ik heb de mappings opnieuw aangemaakt, nu op basis van het ip-adres. Dat werkt vooralsnog. Waarom de servernaam niet meer herkend wordt, maar op andere apparaten wil ik nog wel graag uitzoeken. Maar daarvoor ontbreekt me nu even de tijd. Mijn backups lopen nu in ieder geval weer automatisch en dat was voor nu het belangrijkst.
Mocht ik er achter komen waarom de servernaam van dit apparaat niet meer resolved wordt, maar van andere apparaten nog wel, dan zal ik het hieronder schrijven. En ik sta vanzelfsprekend nog open voor suggesties.

[BMW_Gizzmo]

Wat gebruik je als dns bij je clients. Beste gok: verschil tussen laptop en de rest.

[mopringles]

Was anders, maar is nu hetzelfde. Zonder resultaat. Daar noem je overigens wel een dingetje, sinds enkele maanden verschieten soms de DNS-instellingen van het ene op het andere moment. Was dus ook een heel goede suggestie, zij het dat het niet dé oplossing was.

[mopringles]

Begrijp er inmiddels niet veel meer van. Wilde even testen hoe constistent de mappings waren. Resultaat: niet! Herstartte de computer, geen verbinding met de shares. IP-adres werkte niet meer. Maar nu werkte de servername wel. Mappings weer aangepast. Computer herstart, shares verdwenen, servername werkt niet, maar het IP-adres wel weer.
Mijn netwerkinstellingen zijn nog identiek aan die van mijn andere laptop.

[GoldenBatt]

Heb je niet bij toeval een 2de apparaat op het zelfde ip-adres zitten? Zou dat soort rare problemen kunnen verklaren, al kan het ook wat anders zijn. Geef de nas eens ander ip en blijf het daarop proberen. Die zou altijd moeten werken (mits nas wakker is enz)

[mopringles]

Nee, elk apparaat heeft een uniek ip-adres. Het wijzigen van het ip-adres van de nas heeft helaas ook niet geholpen.

[Arjantje72]

Heb je misschien een virusscanner geïnstalleerd met een ingebouwde firewall zoals Bitdefender?
Ik heb er ook gedonder mee gehad en dat lag toen aan een setting in de firewall.
Weet alleen niet meer de naam, ik kan straks wel even kijken.

[mopringles]

Nee, ik heb geen virusscanner met ingebouwde firewall.

[mopringles]

Inmiddels heb ik dit nu ook bij een andere Windows laptop. De verandering trad op nadat ik die computer verbonden had aan mijn Microsoft-account. Daarvoor had ik alleen een lokaal account. Overigens het moeten switchen na een reboot tussen het IP-adres en de servernaam geldt nu dus óók voor het lokale account. Gisteravond laat vond ik zoekend een metgezel, maar geen oplossing. Een instelling wijzigen in WINS bood geen soelaas.

[mopringles]

Het schijnt een probleem te zijn vanaf versie 2004 vind ik op https://answers.microsoft...-8693-7e543a907dae?page=4. Enkele dagen eerder had ik die tweede laptop inderdaad ook geüpdatet naar deze versie. Dat zal dus de oorzaak zijn. De oplossing heb ik er overigens nog niet gevonden.

[Brahiewahiewa]

mopringles schreef op woensdag 21 oktober 2020 @ 23:32:
... De oplossing heb ik er overigens nog niet gevonden.

De oplossing ligt in name resolution; met het verdwijnen van SMBv1 zijn ook de SMB broadcasts verdwenen die je in staat stelden om de servername (NAS naam) om te zetten in een ip-adres. Probeer iets met DNS of desnoods een hosts file. Als het een synology NAS betreft, kun je WSSD activeren

mopringles schreef op woensdag 21 oktober 2020 @ 16:16:
... Een instelling wijzigen in WINS bood geen soelaas.

Heb jij een WINS server draaien op je netwerk? Bijzonder

[mopringles]

Aanpassen van hosts file heeft ook nog geen succes gehad. Daar had ik ook aan gedacht, helaas. Helaas geen Synology NAS, het is een oudje: Netgear Duo.
Nee, heb ook geen WINS server, was een tipje dat je in instellingen van het TCP/ICP daar een automatische instelling even moest omzetten. Wilde daarmee aangeven dat ik ook dergelijke tips had geprobeerd en geen succes.

Het probleem is dus overigen niet dat Windows de server naam niet in een ip-adres kan omzetten, het probleem is dat hij na het opstarten de vorige stand is vergeten. Dus als mijn mapping op servernaam is, dan kan ik de server na het opnieuw opstarten niet meer bereiken en moet ik het ip-adres gebruiken. Wanneer ik de mapping aanpas naar het ip-adres, dan ben ik na het opnieuw opstarten die verbinding weer kwijt en moet ik de servernaam gebruiken.

[NoahAmber]

mopringles schreef op donderdag 22 oktober 2020 @ 08:20:
Wanneer ik de mapping aanpas naar het ip-adres, dan ben ik na het opnieuw opstarten die verbinding weer kwijt en moet ik de servernaam gebruiken.

Is toevoegen aan 'snelle toegang' niet een optie. Mappen ook na een reboot aanwezig en benaderbaar
Of denk ik nu in de verkeerde richting.

[mopringles]

NoahAmber schreef op vrijdag 23 oktober 2020 @ 19:21:
[...]


Is toevoegen aan 'snelle toegang' niet een optie. Mappen ook na een reboot aanwezig en benaderbaar
Of denk ik nu in de verkeerde richting.

Dat was een kleine moeite maar het waaard om te proberen. Helaas maakte het niets uit.

[mopringles]

Ik heb vandaag een work around gemaakt met twee eenvoudige batchbestandjes. Ik moet nog eens werken aan mijn scriptingkwaliteiten. In een batchfiletje staat niets meer dan: ipconfig /release, hiermee wijs ik de ipadressen opnieuw toe. Dit maakt het mogelijk om weer altijd te verbinden met de servernaam in plaats van het moeten wisselen tussen ip-adres en servernaam. Vervolgens start ik handmatig een ander batchfile op waarin ik door middel van net use z: //servernaam/share de connectie opnieuw tot stand breng. Voor de zekerheid heb ik hiervoor ook staan: net use z: /delete. Later zal ik nog eens testen of het ook zonder kan. Verder wil ik het allemaal nog eens in een scriptingbestandje kwijt, zodat ik het ook in het opstartmenu/taakplanner kwijt kan.
Maar op dit moment ben ik even tevreden, op twee laptops met hetzelfde probleem werkt dit handmatig opstarten meermalen probleemloos.
Het verdient geen schoonheidsprijs, maar het werkt voor mij. En mogelijk lopen er hier grotere geesten rond die op basis van deze informatie een structurelere oplossing kunnen vinden.

[Brahiewahiewa]

mopringles schreef op zondag 25 oktober 2020 @ 20:14:
... In een batchfiletje staat niets meer dan: ipconfig /release, hiermee wijs ik de ipadressen opnieuw toe. Dit maakt het mogelijk om weer altijd te verbinden met de servernaam in plaats van het moeten wisselen tussen ip-adres en servernaam...

Klinkt alsof er iets met je ip-instelling zit te rommelen. Die CyberghostVPN zou ik als eerste verdenken

[AzzKickah]

Dit is een bug van Windows. Drive-mappings zijn sinds Windows XP altijd al gezeik. "Kan niet opnieuw verbinden" bij opnieuw opstarten om wat voor reden dan ook, dubbelklikken op de drive geeft dan een credentials-popup wat niet werkt ook al geef je de juiste gegevens in, werkt pas na handmatig opnieuw de mapping aanmaken, etc, etc.

Jouw work-around is min of meer de beste "oplossing". Batch-files in je startup/Task Scheduler zetten of gewoon op je desktop zodat je ze handmatig kan runnen na inloggen. Niet het fijnste, maar dan werkt het tenminste.

[mopringles]

Brahiewahiewa schreef op maandag 26 oktober 2020 @ 02:28:
[...]

Klinkt alsof er iets met je ip-instelling zit te rommelen. Die CyberghostVPN zou ik als eerste verdenken

Dat was ook een van de eerste gedachten die ik had, maar we zijn nu maanden verder en mijn gedachten ook. Bovendien heb ik nu ook veel lotgenoten getroffen die niet per se een VPN draaien, maar die dezelfde problemen kregen na de upgrade naar 2004.

[mopringles]

Ik kreeg gisteren nog wel van een lotgenoot sysinternals "Autoruns" te draaien en daar onder 'Scheduled tasks' twee Microsoftprogrammaatjes te verwijderen die SMB1 verwijderde. Helaas werkte dat bij mij ook niet, maar hem en anderen wel. Voor de volledigheid noem ik het hier ook even, mocht er in de toekomst nog iemand op dit topic stuiten en dit willen proberen.

[Brahiewahiewa]

mopringles schreef op maandag 26 oktober 2020 @ 17:11:
[...]


Dat was ook een van de eerste gedachten die ik had, maar we zijn nu maanden verder en mijn gedachten ook. Bovendien heb ik nu ook veel lotgenoten getroffen die niet per se een VPN draaien, maar die dezelfde problemen kregen na de upgrade naar 2004.

Doe jezelf en ons een plezier en noteer even je ipconfig voor en nadat je ipconfig /release hebt gedaan.
Dus

ipconfig > c:\<path>\logfile.log
ipconfig /release
ipconfig >> c:\<path>\logfile.log

Waarbij "<path>" moet eindigen in een directory waar je schrijfrechten hebt

[mopringles]

Ik twijfelde even aan het om mijn ipconfig te posten, omdat ik tenslotte nu een workaround heb. Maar om jullie een plezier te doen volgt het hierna.
Overigens heb ik de laatste regel tweemaal uitgevoerd. na de ipconfig /release werd er inderdaad gerommeld met een ip-adres waardoor mijn ethernet verbinding verbroken werd. Het uitgeschakelde WIFI werd automatisch aangezet. Op de verbinding met de shares was dit verder niet van toepassing. Na het terugzetten van de juiste instellingen van mijn ethernetverbinding kon ik de shares ook nog steeds bereiken.
Cyberghost staat uit en ook de bijbehorende ethernetadapter heb ik uitgeschakeld. Dit is in alle gevallen niet van invloed op het kunnen bereiken van de shares.


Windows IP Configuration


Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::800f:2264:f77:b91e%16
IPv4 Address. . . . . . . . . . . : 192.168.1.73
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

Wireless LAN adapter Wi-Fi:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter LAN-verbinding* 10:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter LAN-verbinding* 11:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Ethernet adapter Bluetooth-netwerkverbinding:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Windows IP Configuration


Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::800f:2264:f77:b91e%16
Autoconfiguration IPv4 Address. . : 169.254.185.30
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :

Wireless LAN adapter LAN-verbinding* 10:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter LAN-verbinding* 11:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Wireless LAN adapter Wi-Fi:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::6186:2061:d105:165d%9
IPv4 Address. . . . . . . . . . . : 192.168.1.22
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter Bluetooth-netwerkverbinding:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

Windows IP Configuration


Ethernet adapter Ethernet:

Connection-specific DNS Suffix . :
Link-local IPv6 Address . . . . . : fe80::800f:2264:f77:b91e%16
IPv4 Address. . . . . . . . . . . : 192.168.1.73
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.1.1

Ethernet adapter Bluetooth-netwerkverbinding:

Media State . . . . . . . . . . . : Media disconnected
Connection-specific DNS Suffix . :

[mopringles]

Het probleem lijkt nu eindelijk structureel opgelost in Windows 11. Al enkele weken blijf ik mijn shares zien na het opnieuw opstarten.