Network drive koppelt 9 van de 10 keer niet na reboot

[WRT54G]

Ik heb problemen met het (automatisch) koppelen van netwerk drives op mijn server na reboot.

Ik reboot de server en log in met RDP, open de Windows Explorer en zie mijn netwerk drive met een rood kruis.
Als ik er toch op klik dan blijft ie zoeken en uit eindelijk komt ie met de melding:
An error occured while reconnecting. Microsoft Windows Network: The network path was not found.
This connection has not been restored.

9 van de 10 keer als ik een reboot doe is dit probleem. Een heel enkele keer niet.

Hardware:
Processor: i3 - 2120
Ram 8GB
Boot disk: Samsung 840 Pro SSD

Inmiddels heb ik schone installaties gedaan van Server 2012r2, Server 2016 en Server 2019.
Bij alle heb ik hetzelfde probleem.

Wat heb ik allemaal gedaan:
De server heeft een vast IP adres. (192.168.1.10)
De netwerk kaart heb ik van auto negotiate gehaald en op 1Gbps Full Duplex gezet.
Windows Firewall is disabled.
IPv6 uitgeschakeld.
Power Plan naar high performance gezet

Uitgeschakeld in advanced network settings:
Large Send Offload v2 (IPv4)
TCP Checksum Offload (IPv4)
UDP Checksum Offload (IPv4)

De netwerk drive is aangemaakt middels ip: \\192.168.1.5\share
Ook heb ik de servernaam geprobeerd: \\server01\share

De share komt van een Synology DS415+ (DSM v6.2.1-23824 Update 4) met SMB2 en hoger geactiveerd.
De Syno is natuurlijk al (een aantal keer) herstart.

Het lijkt erop dat door het snelle booten (middels SSD) hij de credentials voor de netwerk drive niet snel genoeg laadt...

Iemand enig idee hoe ik dit kan oplossen?

[ Voor 12% gewijzigd door WRT54G op 20-02-2019 13:36 ]

[Knee-Buckler]

is jou server een DC? en is jou Synology lid van het domein?

Zou het dan niet kunnen zijn omdat je de DC herstart, je domein dus ook even offline gaat en daardoor ook je NAS niet goed werkt???

Iemand een idee of ik hier goed zit?

[WRT54G]

Nee mijn server is geen DC en mijn Syno is dus ook niet lid van een domein.
Alles draait in een WORKGROUP.

De server is op dit moment "helemaal niks". Clean install met alleen Windows updates.

[Knee-Buckler]

En hoe zijn de rechten ingeregeld op die Syno?

Het lijkt mij een Syno probleem te zijn en niet een server probleem..

[ Voor 44% gewijzigd door Knee-Buckler op 20-02-2019 13:54 ]

[Ray]

ik heb ooit zoiets opgelost door een startdelay toe te passen met verwzijzing naar een .bat te draaien die de netwerk koppeling nog een keer opzet

ik gebruik deze methode ook voor een specifiek dsp programma wat anders ook zo snel geladen wordt dat er en nog geen internet opgezet is en dus de online verificatie niet lukt, ergo het programma start dan niet

[ Voor 42% gewijzigd door Ray op 20-02-2019 13:59 ]

[WRT54G]

De gebruiker heeft read/write rechten op de folder die ik heb gemapped.
In de Windows Credential Manager staat deze gebruiker gedefinieerd.

[MAX3400]

Als je 3x een clean install doet van een OS, is het vast ook mogelijk om je focus te verleggen en het eens te testen met Windows 7 en Windows 10?

Daarentegen; als je 9 van de 10x geen en dus 1 van de 10x wel een mapping krijgt, zal er ongetwijfeld ook een logging op je OS zitten?

En, zoals @Ray aangeeft, wat gebeurt er na het booten als je met een delay werkt of desnoods een handmatige mapping (triple test via cmd, powershell en Explorer). Gaat het dan ook niet altijd goed?

En kijk ook eens naar Delayed start van sommige services?

[ Voor 5% gewijzigd door MAX3400 op 20-02-2019 14:14 ]

[WRT54G]

Ik heb zojuist een snelkoppeling gemaakt op de desktop met een verwijzing naar: \\192.168.1.5
Verder geen mappings. Hierbij heb ik hetzelfde probleem.
Direct na boot, login via RDP, open de snelkoppeling: verbindt niet met de Syno share
Een bat file met delay zal dan dus geen oplossing bieden.

9 van de 10x was niet een bewezen aantal. Vandaar ook de zin er nog achter: Een heel enkele keer niet.
Event Viewer laat geen info zien. Hier heb ik natuurlijk in gekeken. ;-)

Windows 10 zou ik nog kunnen proberen echter heb ik deze niet zo 123 liggen.

Delayed services die bij services.msc staan zijn:
Update Orchestra Service
User Access Logging Service
Distributed Transaction Coordinator
Downloaded Maps Manager
Diagnostic Policy Service

Delayed and Triggered:
Software Protection
Connected Devices Platform Service

Dit is een default Server 2019 (Standard Eval) installatie.

[ Voor 22% gewijzigd door WRT54G op 20-02-2019 14:22 ]

[HKLM_]

Het is niet toevallig zo dat je syno in slaapstand / low energy stand staat als je verbinding wilt maken? gebruik je op de Server en de Syno dezelfde netwerk instellingen (op het ip na)?

[ Voor 27% gewijzigd door HKLM_ op 20-02-2019 14:29 ]

[WRT54G]

Nee, Syno staat 24/7 aan en gaat niet in hibernation.

Zelfde netwerk idd: 192.168.1.0/24

[ Voor 26% gewijzigd door WRT54G op 20-02-2019 14:30 ]

[Ronker]

Je zou een batch script kunnen maken wat de netwerk drive eerst verwijderd en daarna weer toevoegd. Dan heb je de minste kans op problemen.

@echo off
net use Z: /delete ( Z drive letter )
net use Z: \\server\SharedFolderName password /user:domain\Username

Mogelijk heb je hier iets aan. Kunt dit gebruiken elke keer als je inlogt.

[Ray]

Ronker schreef op woensdag 20 februari 2019 @ 15:36:
Je zou een batch script kunnen maken wat de netwerk drive eerst verwijderd en daarna weer toevoegd. Dan heb je de minste kans op problemen.

@echo off
net use Z: /delete ( Z drive letter )
net use Z: \\server\SharedFolderName password /user:domain\Username

Mogelijk heb je hier iets aan. Kunt dit gebruiken elke keer als je inlogt.

zoiets gebruikte ik dus ook en vanaf dat moment altijd een werkende mapping gehad

[JeroenV_]

Wellicht dat je iets met gpo's kunt doen, zodat de machine wacht op het netwerk.
Beetje ala dit topic.

[MAX3400]

@JeroenV_ GPO's werken wat rottig op een non-domain machine Allicht kan er iets met lokale policies gedaan worden maar dan nog.

SMB is de standaard voor Windows; als het niet werkt met 3 iteraties Windows Server, lijkt (!!!) het erop dat het niet aan het OS ligt maar iets anders.

@Marcel_EA is je mapping met een Syno user of Syno admin? Kan je eventueel een nieuwe admin aanmaken en dan eens testen?

[WRT54G]

@JeroenV_
Het is idd niet een probleem met dat hij moet wachten op het netwerk, ik verbind namelijk middels RDP naar de machine. Het netwerk moet UP zijn anders kan ik niet verbinden. Het lijkt me in de credentials te liggen.

@MAX3400
Ik heb meerdere gebruikers geprobeerd.
Een non admin user, de Syno admin user. Helaas maakt dit niet uit.


Het aanmaken van een batch bestand ga ik straks nog even testen.
Al ben ik bang dat dat ook niet werkt aangezien de snelkoppeling op mijn bureaublad, dus geen mapping maar een echte snelkoppeling naar de netwerk drive, hetzelfde probleem geeft direct na inloggen.

[WRT54G]

Overigens heb ik dit probleem niet als ik de machine uitrust met een HDD ipv SSD.
Het lijkt toch ergens te liggen aan het snelle opstarten middels SSD.

[WRT54G]

Zojuist een batch file gemaakt en als logon script toegevoegd in GPEDIT.msc (local).
Geeft helaas ook problemen. De schijf wordt niet gekoppeld bij het inloggen.

Als ik de batch iets later draai dan werkt hij wel.

[Ray]

Marcel_EA schreef op donderdag 21 februari 2019 @ 10:00:
Zojuist een batch file gemaakt en als logon script toegevoegd in GPEDIT.msc (local).
Geeft helaas ook problemen. De schijf wordt niet gekoppeld bij het inloggen.

Als ik de batch iets later draai dan werkt hij wel.

dat is dus precies wat we voorstellen door die startup delay toe te passen en die dan dit script te laten draaien

ik gebruik zelf

https://www.r2.com.au/page/products/show/startup-delayer/

dus dat proggie wacht tot de boot compleet is en bv 10 sec later laat je dat script draaien

zoals eerder gezegd doe ik dat op mijn muziek server. na 10 sec de dsp die anders geen validatie krijgt en dan pas na 30 sec foobar

doe ik dat niet start foobar foor de dsp zonder validatie en is er geen muziek

[ Voor 30% gewijzigd door Ray op 21-02-2019 10:12 ]

[MAX3400]

@Ray het is toch van de gekke dat je aanvullende meuk moet inzetten voor iets simpels als een SMB-mapping???

[Ray]

MAX3400 schreef op donderdag 21 februari 2019 @ 10:14:
@Ray het is toch van de gekke dat je aanvullende meuk moet inzetten voor iets simpels als een SMB-mapping???

tja soms is het niet anders. de eerste keer , al weer 12 jaar geleden hadden we zoiets met een cliënt die op geen enkele manier wou verbinden met een share op de server dus een compleet software pakket werkte daardoor niet. toen ook op zo'n manier opgelost

waar het dan precies aan ligt kom je wellicht niet achter maar als het met een script op te lossen is en dit werkt tja....

[WRT54G]

Met een timeout van 5 seconden werkt het helaas nog steeds hetzelfde.
Het lijkt wel of hij bij de eerste keer verbinden naar de share zijn credentials niet herkend.
Als ik de batch nu draai koppelt ie wel.

Eventviewer geeft ook geen info.

Ben nu zelfs op het punt om de HDD terug erin te zetten en deze maar te gaan gebruiken...

[Ray]

Marcel_EA schreef op donderdag 21 februari 2019 @ 10:27:
Met een timeout van 5 seconden werkt het helaas nog steeds hetzelfde.
Het lijkt wel of hij bij de eerste keer verbinden naar de share zijn credentials niet herkend.
Als ik de batch nu draai koppelt ie wel.

Eventviewer geeft ook geen info.

Ben nu zelfs op het punt om de HDD terug erin te zetten en deze maar te gaan gebruiken...

langere time out ? script 3x laten draaien met tussenpozen ?

[WRT54G]

Zojuist nog wat meer getest.
Ik heb de mappings verwijderd en het startup script ook.

Als ik direct na inloggen het volgende uitvoer:

code:

net view 192.168.1.5

Krijg ik de volgende melding:

code:

System error 53 has occurred.
The network path was not found.

[ Voor 44% gewijzigd door WRT54G op 21-02-2019 11:33 ]

[WRT54G]

Zojuist een point 2 point verbinding opgezet met de machine en de Syno.
Dus een rj45 tussen beide apparaten en geen andere netwerk apparatuur (switch etc).

Hierbij heb ik hetzelfde probleem!
Als ik de snelkoppeling naar de shares open (\\192.168.1.5) of net view 192.168.1.5 doe na het inloggen dan lijkt hij geen verbinding te krijgen. Pingen naar 192.168.1.5 werkt overigens wel en krijg netjes een reply.

[MAX3400]

Dom denken hoor; worden de IP's uitgedeeld (reserved) via een DHCP-server of staan ze keihard ingetikt per device?

[WRT54G]

Staan op beide apparaten (server + Syno) hard erin.
DHCP (en andere netwerk zaken, switch vlan etc) heb ik geëlimineerd dmv de p2p verbinding.
Er zat een rj45 tussen beide machines en maakten direct contact (ook op vast IP).

En nee, zeker niet dom gedacht.
En sowieso waardeer ik het meedenken!
Maar DHCP had idd een slowdown kunnen veroorzaken omdat het IP niet vast staat.
Dus snap je opmerking maar helaas is dat het niet.

[ Voor 37% gewijzigd door WRT54G op 21-02-2019 12:27 ]

[MAX3400]

Juist andersom; ongeacht je p2p: DHCP met reservations en ARP-cache zouden juist de "snelheid" tussen endpoints moeten verhogen.

Niet dat je server nu constant eerst een broadcadt doet etc en tegelijkertijd failt met de mapping.

[Brahiewahiewa]

Hoe log je aan op de synology? Met een guest user, met een locale user op de windows machine of met een user van de synology?

[WRT54G]

@MAX3400
Hmmm ik snap je. Is iets wat ik zou kunnen proberen.
Heb pfSense op de achterkant draaien dus kan makkelijk de reservatie erin zetten en proberen.
Neem aan dat alleen de server dan op DHCP reservation moet staan en de Syno op vast kan blijven?

@Brahiewahiewa
Op de server log ik in met een lokaal account (administrator), dus geen AD account.
De Syno benader ik met een lokaal Syno account (Marcel).

[MAX3400]

@Marcel_EA komt ie nu mee; houdt pfSense niet wat tegen in "normale" opstelling?

En ik persoonlijk zet nergens op devices vaste IP's; alles via reservations op de goede DHCP-server op het betreffende VLAN.

[Brahiewahiewa]

Marcel_EA schreef op donderdag 21 februari 2019 @ 12:39:
...
De Syno benader ik met een lokaal Syno account (Marcel).

Dat lijkt dan erg veel op de bug met het saven van cached credentials, die ook Windows 10 (1809) nog plaagt.
Die bug zal ondertussen ook wel in de windows server versies zitten
Waarom wil je überhaupt nog een driveletter op je netwerkdrives? UNC-paden hebben geen last van deze bug

[WRT54G]

@MAX3400
Aangezien ik een p2p heb opgezet (en dus zonder tussenkomst van allerlei andere zaken: switch, VLAN, pfSense etc) en dan nog de problemen heb ligt het niet aan pfSense of andere netwerk apparatuur en wordt dat niet tegengehouden, lijkt me aangezien dat allemaal niet aanwezig is met p2p.
Vandaar dat ik net een levensgrote kabel van mijn Syno naar mijn server heb getrokken om dit te checken.

Reservations ga ik straks nog ff checken en kom ik op terug!

@Brahiewahiewa
Daar dacht ik eerst ook aan echter heb ik ook Server 2012r2 geprobeerd en zover ik weet moet 2012r2 deze bug niet hebben. Overigens heb ik het probleem ook zonder drive letters. Ik heb een simpele snelkoppeling op mijn desktop met als inhoud \\192.168.1.5

[ Voor 4% gewijzigd door WRT54G op 21-02-2019 12:48 ]

[WRT54G]

Helaas met reservations blijft het probleem er ook.

[Brahiewahiewa]

Marcel_EA schreef op donderdag 21 februari 2019 @ 12:48:
...
@Brahiewahiewa
... Ik heb een simpele snelkoppeling op mijn desktop met als inhoud \\192.168.1.5

Tijd voor wireshark

[WRT54G]

Ik heb weer wat tijd gehad om wat uitgebreider te testen.
Het probleem lijkt hem in de SMB share vanaf de Syno te komen.

Het volgende heb ik getest:

Server 2016 machine met een snelkoppeling (of netwerk mapping maakt niet uit) naar de Syno.
Dit geeft bovenstaande problemen na het rebooten.

Andere Server 2016 machine (met zelfde SSD) met een snelkoppeling (of netwerk mapping maakt niet uit) naar de Syno.
Dit geeft bovenstaande problemen na het rebooten.

Server 2016 machine met een snelkoppeling (of netwerk mapping maakt niet uit) naar een andere Server 2016 machine middels SMB.
Na het rebooten totaal geen problemen. Netwerk drive is direct gekoppeld en geen vertragingen.


Beide zijn gekoppeld middels SMB 3 (dialect 3.1.1) dus daar zit ook geen verschil in.
Geen idee wat nu precies het probleem is maar het is en blijft een vervelend iets!
Maar blijkbaar iets wat aan de Syno ligt.

[WRT54G]

Problem solved!!

Het probleem lag hem uit eindelijk in de SMB sharing van de Synology.
Alle settings heb ik inmiddels gehad (behalve terug naar SMB1, voor logische redenen ).

Het bleek deze setting te zijn:
Disable multiple connections from the same IP address

Deze heb ik aangevinkt waarna alles weer soepel loopt.
Inmiddels wel 50x een reboot gedaan en elke keer wordt de netwerk schijf netjes gekoppeld, kan ik net view direct gebruiken en werkt de snelkoppeling op het bureaublad direct na het inloggen.

Bron:
Synology KB


Iedereen bedankt voor het meedenken!