Jul 01, 2020, updated at Apr 21, 2022 (UTC)

10471

W10 Netzlaufwerk alter SAMBA Server funktioniert nicht mehr seit Update 2004

Hallo zusammen,

ich habe bei allen Windows 10 mit Update 2004 das Problem, dass Verbundene Netzlaufwerke eines älteren SAMBA Servers nach dem Neustart nicht mehr funktionieren. Bei den 1909 Computern funktioniert es einwandfrei.

Ich kann das Laufwerk über die cmd trennen und neu hinzufügen... Beim nächsten Neustart des PCs wieder das gleiche Problem.

Kennt jemand das Problem?

Vielen Dank!

Please also mark the comments that contributed to the solution of the article

Content-Key: 583614

Url: https://administrator.de/contentid/583614

Printed on: April 18, 2024 at 01:04 o'clock

57 Comments

Latest comment

Hi,

das tritt nicht nur bei Samba-Servern auf. Einfach einmal das Netzlaufwerk trennen, und neu verbinden. Ich geh mal davon aus, dass das Laufwerk per GPO gemappt wird, einfach ein kleines Skript für das abmelden erstellen, welches das Netzlaufwerk trennt, sodass es beim anmelden einfach neugemappt wird.

Zusätzlich einmal nachschauen, ob durch das Upgrade die Untrstützung für die SMB 1.0/CIFS-Dateifreigabe deaktiviert wurde.

Systemsteuerung-> Programme und Funktionen -> Windows Features aktivieren oder deaktivieren

🖖

Ne das Laufwerk wird manuell hinzugefügt. Es scheint so als würde es hier ein Problem geben.

Wenn ich das Laufwerk mit NET USE hinzufügen dann will er beim nächsten mal die Credentials erneut... obwohl ich /savecred und /persistent:yes verwende.

Wenn ich das Laufwerk manuell hinzufüge und starte den PC neu, kommt die Fehlermeldung... JEDES MAL.
Wenn die Fehlermeldung aktiv ist, kann ich mit NET USE L: /delete das Laufwerk auch nicht entfernen. Da Kommt Fehlercode 67...

Irgendwas ist da in dem Update 2004 faul...

Das nächste komische... möchte ich mit dem Explorer auf den SAMBA Server zugreifen... kommt folgende Fehlermeldung:

Bei den 1909 Rechnern funktioniert alles einwandfrei...

Zitat von @leon123:

Das nächste komische... möchte ich mit dem Explorer auf den SAMBA Server zugreifen... kommt folgende Fehlermeldung:

Bei den 1909 Rechnern funktioniert alles einwandfrei...

Hast Du kontrolliert ob die SMB 1.0 Freigabe aktiviert ist?

🖖

Ja ich hab SMB 1.0 zum test auch schon deaktiviert und wieder aktiviert... leider ohne Erfolg.

Zitat von @leon123:

Wenn die Fehlermeldung aktiv ist, kann ich mit NET USE L: /delete das Laufwerk auch nicht entfernen. Da Kommt Fehlercode 67...

Und wenn die Fehlermeldung nicht aktiv ist?
🖖

Ich muss das dann manuell mit der Maus aus dem Explorer entfernen, sonst bekomme ich das Laufwerk nicht los...

Das eigenartige ist nur, dass wirklich jeder Rechner mit 2004 betroffen ist. Auch neu installierte. Auch eine VM mit 1909 funktioniert und mit 2004 funktioniert nicht.

Entweder ist das eine GPO Geschichte oder einfach ein BUG weil Microsoft wieder an der Sicherheit vom SMB Protokoll rumgedoktort hat?

Ich weiß SMB1 ist nicht ideal, aber das geht einfach nicht anders. Diesen Server kann man nicht mehr updaten...

Wenn ich das richtig verstehe, speichert Windows nur den Benutzername un das Passwort nicht, um das LW wieder herzustellen?

🖖

Das ist das zweite Problem... Mit Net Use muss ich nach jedem Neustart das PW wieder eingeben.

Wenn ich das Netzlaufwerk manuell hinzufüge, kommt nach dem Neustart die Fehlermeldung...

Ich hab hier die gleiche Problematik gefunden:
https://answers.microsoft.com/de-de/windows/forum/all/nach-funktionsupda ...

https://answers.microsoft.com/de-de/windows/forum/all/win10-upd-2004-auf ...

Die Lösungsansätze haben nicht geholfen, bei mir hilft auch nicht den Schnellstart zu deaktivieren...

Kannst Du auf dem Samba Server Deinen Benutzernamen und Dein Passwort anlegen? Das wäre dann wohl das Einfachste.

🖖

Hab ich auf einem NAS probiert, das geht auch nicht... Wenn ich NET USE verwende will er immer das PW und wenn ich es von Hand hinzufüge über den Windows Explorer, dann geht es gar nicht...

Was geht ist ein Batch File (Mit lesbaren Passwörtern) in den Autostart mit /persistent:no ... Evtl. muss ich mal schauen, dass ich GPOs verwende soweit es geht (Wenn es geht)...

Aber ist schon komisch, dass es mit der neu aufgesetzten 1909 geht und mit der neu aufgesetzten 2004er Windows 10 Version nicht... Microsoft hat sicher an den Rechten gespielt....

Zitat von @leon123:
Ich weiß SMB1 ist nicht ideal, aber das geht einfach nicht anders. Diesen Server kann man nicht mehr updaten...

SMB2 kam mit Version 3.6 🙄

Vielleicht ein guter Zeitpunkt, in einen neuen Server zu investieren ...

Zitat von @leon123:
Aber ist schon komisch, dass es mit der neu aufgesetzten 1909 geht und mit der neu aufgesetzten 2004er Windows 10 Version nicht... Microsoft hat sicher an den Rechten gespielt....

Ist das Feature "Unterstützung für SMB 1" denn installiert?

Ja natürlich ohne SMB1 geht garnichts...

Mann... Neuer Server geht nicht, es gibt NIEMANDEN der die darauf installierte Software neu installieren kann... Sonst würde ich das tun!!!

Zitat von @leon123:

Ja natürlich ohne SMB1 geht garnichts...

Mann... Neuer Server geht nicht, es gibt NIEMANDEN der die darauf installierte Software neu installieren kann... Sonst würde ich das tun!!!

Und was macht ihr, wenn der Server die Füße von sich streckt?

🖖

Ich hoffe, dass es sich um weitere Software handelt, die du bislang nicht erwähnt hast. Denn Samba zu installieren dauert - inklusive neuem Betriebssystem - maximal 30 Minuten ...

Zitat von @144144:

Ich hoffe, dass es sich um weitere Software handelt, die du bislang nicht erwähnt hast. Denn Samba zu installieren dauert - inklusive neuem Betriebssystem - maximal 30 Minuten ...

Da ist ja mal von auzugehen, denn einen Samba Server sollte doch jeder, der halbwegs Ahnung hat, installiert und konfiguriert bekommen. Dann wäre das NIEMAND nicht korrekt.

🖖

Wenn ich sage man kann den Server nicht neu machen, dann kann man das nicht ;)

Zitat von @leon123:

Wenn ich sage man kann den Server nicht neu machen, dann kann man das nicht ;)

Wenn man(n) das nicht kann, einfach mal frau fragen. ;)
Und wenn da Software verwendet wird die es nicht mehr gibt und wo sich keiner mehr zuständig sieht,
dann solltest du mal ganz schnell im eigenen Interesse das Weite suchen.

Zitat von @leon123:

Wenn ich sage man kann den Server nicht neu machen, dann kann man das nicht ;)

Ruhig, denk an Deinen Blutdruck.

Nichts desto Trotz solltest Du schon mal einen Worst Case Plan haben, wenn der Server den Dienst quitiert. Am Besten sofort zum Chef rennen und fragen, was passieren soll, wenn es soweit ist. SCHRIFTLICH bestätigen lassen. Dann bist Du wenigstens nicht Schuld. Weil, wenn es NIEMAND kann, dann hat sich auch noch NIEMAND darüber Gedanken gemacht, was passiert wenn...

🖖

Hi,

um zum Thema zurückzukehren: gleiches Problem bei mir.

Vor Upgrade auf 2004 ist der Zugriff auf SMB1-Freigaben (hier Synology DiskStation) möglich, nach Upgrade nicht mehr.

Es wurden bereits die Tipps "SMB1-Unterstützung am Client deinstalliert, und wieder installiert", zudem "Schnellstart-Unterstützung deaktiviert" ausgeführt - keine Lösung.

Scheint also ein Problem mit der SMB1-Unterstützung zu geben...
Ich suche auch noch weiter.

Ich bezweifle, dass es sich tatsächlich um ein Problem handelt. SMB 1 sollte schon längst tot sein.
Zumindest Synology sollte doch auch höhere Versionen unterstützen?!

Ja ja, immer diese Verschlimmbesserungen von M$. So langsam sollte man denen den ganzen Aufwand den man betreiben muß um das Netzwerk, nach einem Update oder Upgrade, wieder zum Laufen zu bekommen in Rechnung stellen. "Windows as a Service" selten so gelacht.

Schlimm finde ich auch, daß einfach Registrywerte, die man mühsam eingepflegt hat, einfach durch ein Update entfernt werden. Sowas geht gar nicht. Das macht man ja nicht nur so zum Spaß. Scheint denen aber egal zu sein.

🖖

Zitat von @144144:

Ich bezweifle, dass es sich tatsächlich um ein Problem handelt. SMB 1 sollte schon längst tot sein.

Ist doch völlig egal, Microsoft hat dafür zu sorgen, das Windows kompatibel bleibt. Wenn ich irgendwo in der Ecke noch einen Linux Server stehen habe, der mit einer uralt Samba Version läuft und auf dem meine ganzen Kundendaten liegen, muß ich darauf zugreifen können (ist ein Extrembeispiel, aber irgendwo garantiert noch im Einsatz). Es entscheidet nicht Microsoft ob es vernünftig und sicher genug für mich ist.
Und ich habe gerade, nach einem Upgrade eines Rechners auf 2004, das gleiche Problem. Bei mir ist es allerdings ein Server 2003, der nur noch zur Datenhaltung dient. Es betrifft aber auch nicht alle 2004 Versionen. Mal sehen, ob ich den Unterschied finde.

🖖

Zitat von @Dr.Bit:
Ist doch völlig egal, Microsoft hat dafür zu sorgen, das Windows kompatibel bleibt. Wenn ich irgendwo in der Ecke noch einen Linux Server stehen habe, der mit einer uralt Samba Version läuft und auf dem meine ganzen Kundendaten liegen, muß ich darauf zugreifen können

Lol? Warum sollte M$ dafür sorgen, dass Software von Drittanbietern dauerhaft funktioniert? Im welcher Welt lebst du?
Dass das auch in der eigenen Ecosphäre auf einmal nicht mehr tut, ist schon eher deren Bier aber auch hier kann man durchaus irgendwann mal alte Zöpfe abschneiden. Ein Großteil der Schwachstellen in modernen Windows-Systemen rührt von irgendwelchen Kompatibilitätsschnittstellen her.

Windows ist nunmal ein Betriebsystem, nicht mehr und nicht weniger, und nach meinem Verständnis hat ein Clientbetriebsystem dafür Sorge zu tragen, das Software, die für dieses System entwickelt wurde, auch uneingeschränkt funktioniert. Hiermit meine ich nicht, daß das BS für die Bugs und inkompatilitäten der Software verantwortlich ist, sonder alles zur Verfügung zu stellen muß, was für den Betrieb der Software relavant sein könnte. Wenn dem nicht so ist, ist natürlich M$ dafür zuständig. Und einfach die Unterstützung für ein bewährtes (wenn auch nicht mehr sichers) System klamheimlich einzustellen um ihr eigenes SMB 3 Protokoll durchzusetzen geht gar nicht. Meine Meinung!

So ein Ding hatte Apple mit ihren Iphones und dem WLAN Protokoll auch schon einmal gebracht. Die IPhones konnten partout nicht mit Netgear Accesspoints und WLAN Routern. Netgear mußte allen Enstes für alle betroffenen Geräte ein FW Update entwicken und betreit stellen, weil Apple sich nicht gerührt hat. Auch ein Unding.

🖖

Sehe ich völlig anders. Es ist völlig richtig, das SMB-3-Protokoll durchzudrücken. Jeder heult immer rum, dass Windows so unsicher ist, aber will dann auf Teufel komm raus uralte Protokolle bis zum Sanktnimnerleinstag benutzen können.
Und das Betriebssystem ist mitnichten dafür zuständig, mit allen Implementierungen irgendwelcher Drittanbieter zu funktionieren. Da mag Samba noch so beliebt sein, es ist nunmal ein Fremdprodukt.
Und zu der Sache mit Apple: völlig richtig so. Auch hier will jeder Sicherheit, aber wenn dann mal einer Ernst macht, ist das Geschrei wieder groß.

Zitat von @144144:

Sehe ich völlig anders. Es ist völlig richtig, das SMB-3-Protokoll durchzudrücken. Jeder heult immer rum, dass Windows so unsicher ist, aber will dann auf Teufel komm raus uralte Protokolle bis zum Sanktnimnerleinstag benutzen können.

Es geht darum, das MS es einfach so beschließt. Das geht nicht. Grundsätzlich ist es natürlich richtig, das SMB 3 zu implementieren für homogene Windows Netze, aber es ist nunmal ein Microsoft Ding und somit nicht Standard. Für heterogene Netze, sagen wir mal ausbaufähig.

Und das Betriebssystem ist mitnichten dafür zuständig, mit allen Implementierungen irgendwelcher Drittanbieter zu funktionieren. Da mag Samba noch so beliebt sein, es ist nunmal ein Fremdprodukt.

Selbstverständlich ist das BS dafür zuständig, wer denn sonst? Die Hersteller von Frendsoftware bekommen die Spezifikationen von MS und entwickeln danach ihr Produkt. Und wenn Microsoft dann die Spezifikationen ändert läuft das Produkt nicht mehr? Irgendwie suboptimal.

Und zu der Sache mit Apple: völlig richtig so. Auch hier will jeder Sicherheit, aber wenn dann mal einer Ernst macht, ist das Geschrei wieder groß.

Wenn´s denn wenigstens der Sicherheit gedient hätte. Die haben einfach nur versucht ihr eigenes Ding zu machen. Hat sich mit dem Nachfolger dann aber schon wieder erledigt gehabt. Wohl doch zuviel Gegenwind gewesen.

🖖

Zitat von @Dr.Bit:
Es geht darum, das MS es einfach so beschließt. Das geht nicht. Grundsätzlich ist es natürlich richtig, das SMB 3 zu implementieren für homogene Windows Netze, aber es ist nunmal ein Microsoft Ding und somit nicht Standard. Für heterogene Netze, sagen wir mal ausbaufähig.

Niemand zwingt dich, Samba einzusetzen. Die Version 1 ist uralt und muss irgendwann mal weg. Ob das einfach so beschlossen wurde oder ob das absehbar war, weiß ich nicht. Richtig finde ich es trotzdem.

Deren Produkt, deren Regeln. Btw beherrscht Samba alle Protokollversionen, man muss halt auch mit den Servern am Ball bleiben (irgendwie ja der Stein des Anstoßes in diesem Thread).

Du scheinst in der Sache mehr zu wissen als ich. Auf die Schnelle habe ich auch keine näheren Informationen dazu gefunden, was der Auslöser war.

Zitat von @144144:

Deren Produkt, deren Regeln.

Genau der falsche Denkansatz, damit begiebst Du Dich in die Abhängigkeit und läßt es einfach nur noch über dich ergehen. Richtig müßte es lauten: Deren Produkt, mein Eigentum, mein Netzwerk, meine Regeln. Es geht einfach nur keiner, der auch was ausrichten könnte, dagegen vor.

Win 10 ist nicht umsonst nicht besonders beliebt, wenn ich das aus diversen Foren richtig interpretiere.

🖖

Zitat von @Dr.Bit:
Richtig müßte es lauten: Deren Produkt, mein Eigentum, mein Netzwerk, meine Regeln. Es geht einfach nur keiner, der auch was ausrichten könnte, dagegen vor.

Niemand zwingt dich, Windows einzusetzen oder zu updaten. Jeder, der von M$ abhängig ist, ist das freiwillig.

Win 10 ist nicht umsonst nicht besonders beliebt, wenn ich das aus diversen Foren richtig interpretiere.

Ich habe genau den gegenteiligen Eindruck. Kommt aber sicherlich auf den Blickwinkel an.

Zitat von @144144:

Zitat von @Dr.Bit:
Richtig müßte es lauten: Deren Produkt, mein Eigentum, mein Netzwerk, meine Regeln. Es geht einfach nur keiner, der auch was ausrichten könnte, dagegen vor.

Niemand zwingt dich, Windows einzusetzen oder zu updaten. Jeder, der von M$ abhängig ist, ist das freiwillig.

Das ist wohl grundsätzlich richtig, allerdings zwingen Dich die Softwarehersteller dazu. Datev oder Tobit oder... gibt es leider nicht für Linux. sonst wäre das längst erledigt. Ja, und auch richtig: dafür kann Microsoft nichts.

Win 10 ist nicht umsonst nicht besonders beliebt, wenn ich das aus diversen Foren richtig interpretiere.

Ich habe genau den gegenteiligen Eindruck. Kommt aber sicherlich auf den Blickwinkel an.

Genau.

🖖

Und, bist Du schon weitergekommen? Habe dasselbe Problem, tritt aber sporadisch mit einer alten Qnap auf.

Wie hier im Forum vorgeschlagene werde ich eh statt der Qnap 469 einen Server um 20.000 € aufsetzen, damit ich Windows 10 genüge tue und immer total uptodate bin was MS von mir verlangt, aber da das ganze vorher auch geklappt hat, bleibe ich eher dabei und schaue dass ich den Fehler so finde.

Es hängt auf jedenfall zu 100% mit SMB 1 zusammen und dem Windows 10 2004 Update.

Das QNAP kann aber definitv SMB 3.11, da verstehe ich nicht, wo das Problem liegt.

Das Problem geht ja von Windows 10 nach dem Update aus, wurde aber auch genau so beschrieben. Mit der Qnap hat das wenig zu tun.

Das Problem geht von der uralten Protokollversion des eingangs erwähnten, nicht mehr updatebaren, Servers aus.
Du hast doch von deiner QNAP angefangen!?

Noch einmal: das Problem geht von Windows 10 2004 aus, bei 1909 war es ok.

Aber ja, neu ist immer besser, Raid1 ist kein Backup und Linux ist super. Und wenn morgen wieder ein Update rauskomnt und die 2 Jahre alte Hardware nicht mehr läuft dann schmeiss ich wieder alles raus und kauf mir was neues.

Und in der Zwischenzeit würde ich mir Antworten wünschen die 1) kein Klischee sind und 2) auf die Fragestellung eingehen und nicht nur für den Beitragszähler da sind. Von den Posts zu diesem Thema dreht sich so gut wie keiner um das Thema, der Rest ist Geschwätz, was mit dem Thema 0 zu tun hat.

Wenn das Priblem sowohl bei der Qnap mit FW 3.XX auftritt als auch mit einem uralten Server, dann ist wer schuld?

Moinsens.

Bei mir geht es wieder. Ich habe mal geschaut, was passiert, wenn ich den OnBoard Relatek LAN der Clients deaktiviere und eine Intel Pro 1000 als AddOn Karte einsetze. Mit der funktioniert es. Als Übergangslösung reicht es erst einmal für mich. Irgendwie scheint 2004 nicht so gut auf Realtek zu sprechen zu sein. In anderen Foren kann man auch nachlesen, daß wohl auch die WLAN, Bluetooth und Soundchips von Realtek nicht so wirklich wollen.

🖖

Hmm bei mir sind alle Computer betroffen und es sind alles Dell mit Realtek Karten. Da müsste ich mal zum test so eine Intel Pro 1000 Karte kaufen.

Der GF weiß bescheid, dass sein System seit 12 Jahren nicht mehr gupdatet wurde und es keinen mehr gibt, der das kann. Ich teste regelmäßig mein Veeam Backup. Solange das auf dem Testserver mit VM 6.5 noch läuft kann ich ruhig schlafen.

Zitat von @Dr.Bit:
wenn ich den OnBoard Relatek LAN der Clients deaktiviere und eine Intel Pro 1000 als AddOn Karte einsetze. Mit der funktioniert es.

Heute frischer Treiber-Release bei Realtek: 10.042
https://www.realtek.com/en/downloads

Ich bin hier immer noch nicht weiter gekommen... Überall das gleiche Problem mittlerweile...

2004 und alte Netzlaufwerke ist wohl nicht mehr?

Mal so ne ganz doofe Idee, mal für die IP in der Systemsteuerung "Windows Anmeldeinformationen" die Daten zum Server fix hinterlegt, so dass es nicht mehr über die Netzlaufwerke gespeichert wird?

Ich kann dein Phänomen leider irgendwie nicht nachstellen. Hier klappen die SMB-Netzlaufwerke auch unter 2004, sowohl mit SMB 2 als auch SMB 3.

Mal ganz doof, zur Problematik, dass das Laufwerk nicht wieder verbunden werden kann: Mal ein Abmeldeskript gebastelt, welches beim abmelden das Laufwerk trennt und eine GPO/oder auch ein Abmeldeskript, welches das Laufwerk wieder verbindet ausprobiert.

Ggf. hilft es, wenn du mitteilst welche Version du exakt von Windows 10 2004 verwendest. Auch die Samba Version auf dem Server wäre ggf. sinnvoll zu nennen.

Sollte dies bereits passiert sein, bitte ich es zu entschuldigen, der Thread ist etwas unübersichtlich in der Darstellung bei mir.

Hi,
seit dem Update eines Laptops auf 2004 liefern meine Netzlaufwerke zu einer Synology-NAS die Fehler "Der lokale Gerätename wird bereits verwendet" und "Mehrfache Verbindung zu einem Server...".
4 weitere PCs ohne dieses Update haben weiterhin eine fehlerfreie Verbindung zur NAS. Habe den Vorschlag von c0d3.r3d getestet, Laufwerke zu trennen und neu anzulegen. Das klappt bei mir. Habe jetzt 2 Scripte angelegt, die zum Start ausgeführt werden:
"net use * /delete" um alle Verbindungen zu trennen und für jedes Netzlaufwerk "net use Lfw: \\Server\Freigabe". Bis zu einer Lösung werde ich damit leben (müssen).
Das Problem scheint ja an Win10 2004 und / oder der Netzwerkkarte zu liegen.

Win10
Version 2004
Build 19041.508

Netzwerkadapter: Qualcomm Atheros AR8151 PCI-E

Es ist ein alter Suse 9.0, ich kann den aktuell noch nicht updaten. Wann das passieren wird, liegt nicht in meiner Hand, dafür bin ich nicht zuständig. Hier geht nur SMB1.

Das mit den Skripten per GPO funktioniert.

Es sind aber nicht alle Rechner in der Domäne (sind in einem eigenen VLAN und dürfen ausschließlich auf diesen Server zugreifen). Das sind Produktionsrechner von Maschinen die aber dieses Laufwerk benötigen. Hier habe ich das Skript in den Autostart, das funktioniert auch...

Es ist eindeutig kein Problem mit der SMB-Version.

Wenn der PC ohne Netzwerkverbindung gestartet wird und man dann erst mit "net use * ... /persistent:yes" ein Netzlaufwerk erstellt funktioniert die Verbindung.
Wenn man dann den PC neu startet, und das Netzlaufwerk nicht mehr läuft, hat das mit SMB absolut nichts zu tun. Da kann wohl Win10 Version 2004 die Netzverbindung nicht mehr so aufbauen, wie es vor dem Neustart war.

Ich hab mittlerweile bei einigen PCs das Problem, dass ich nicht einmal mehr über die IP Adresse auf das alte NAS zugreifen kann...

Ich bekomme so langsam echt ein Problem.

Hab's noch einmal Schritt für Schritt durchgegangen:

PC gestartet, Powershell gestartet
Mit "net use" angezeigt, ob Netzlaufwerke angelegt sind
Mit "net use * /delete /y" alle vorhandenen Netzlaufwerke gelöscht
Mit "net use /persistent:no" einstellen, dass Verbindungen nicht gespeichert werden. Dadurch kann ein zukünftiges Löschen entfallen.
Nach den 2 vorigen Eingaben mit "net use" prüfen, dass keine Verbindungen mehr bestehen und angezeigt wird: "Neue Verbindungen werden nicht gespeichert".
Mit "net use Lfw: \\Server\Ordner" die Netzlaufwerke anlegen. Testen, ob die Verbindungen funktionieren.

PC neu starten, mit "net use" sicherstellen, dass tatsächlich keine Verbindungen mehr existieren und dass angezeigt wird, dass neue Verbindungen nicht gespeichert werden.
Die Netzlaufwerke wieder manuell oder per Script anlegen.

Wenn das alles fehlerfrei funktioniert hat, dann sollte es eigentlich weiterhin am getesteten PC funktionieren.
Wenn nicht, in welchem Schritt trat der Fehler auf ?

Also bei mir war jetzt die Lösung alle Häkchen bei SMB/CIF raus, PC neu starten, anschließend alle Häkchen wieder rein, PC neu starten... Das hatten jetzt 3 Computer das Problem. Bei 2 gings so.

Habe zum Testen mal meine Synology NAS umgestellt auf nur SMB1.
Am PC habe ich bei Windows-Features nur ein Häkchen gesetzt bei "SMB 1.0/CIFS-Client".
Habe den PC neu gestartet und eine Netzlaufwerk testweise persistent erstellt: "net use Lfw: \\Server\Ordner /persistent:yes".
Der Zugriff auf das Netzlaufwerk funktioniert.
Habe den PC dann neu gestartet und der Zugriff auf das Netzlaufwerk funktioniert immer noch, auch bei mehrmaligem Neustart.
Bei der jetzt vorliegenden Einstellung kann ich auf die Scripts zum Löschen / Aufbauen der Netzlaufwerke verzichten.
Genau das hat bei mir vorher nicht funktioniert mit SMB1 bis SMB3 an der NAS und ohne SMB1-Unterstützung am PC.

Da gibt es noch etwas zu untersuchen .....

War das Netzlaufwerk mit Benutzer / Passwort?

Ich vermute hier liegt das Problem.

Ja,

Benutzer und Passwort.
"Net use Lfw: \\Server\Ordner \persistent:yes"
Dann "Benutzer" return und "Passwort" return.

Hallo. Ich habe es gelöst bekommen durch erstellen diesen reg-Eintrags:

HKEY_CURRENT_USER\NETWORK\
jew. Netzlaufwerk auswählen
Neuer Dword-Wert(32bit) namens „ProviderFlags“ mit Wert 1 (Hexa)
dann den Rechner neustarten

Auf meinem Laptop bekam Windows jetzt zwangsweise das Update auf Version 2004, was mich zu weiteren Untersuchungen brachte.
Bei mir zeigt sich folgendes:

Habe 2 Netzlaufwerke persistent angelegt:
net use S: \\nas\Büro /persistent:yes
net use U: \\nas\Windows /persistent:yes

Nach Neustart zeigt sich beim Öffnen von S: ein Anmeldefenster mit vorgegebenem User "nas\Ich".
Wenn ich das Fenster ohne Anmeldung schließe und U: öffne, kommt ein Anmeldefenster mit freier Eingabe von User und Passwort.

Die Folge ist, dass die Reihenfolge des Öffnens/Anmeldens eine Rolle spielt.

Melde ich zuerst S: mit Passworteingabe an, ist auch danach U: ohne Anmeldung korrekt verbunden.
Melde ich zuerst U: an, und gebe wie gewohnt als User nur "Manfred" an, dann klappt die Verbindung von U:, aber öffne ich dann S:,

kommt die Fehlermeldung "Fehler bei der erneuten Verbindungswiederherstellung von S: ... Mehrfache Verbindungen zu einem Server....trennen Sie alle früheren Verbindungen....".

Melde ich aber nach einem Neustart U: an als User "nas\Ich", dann klappt danach auch das Öffnen von S: einwandfrei.

Dies habe ich getestet, indem ich den Netzwerkstecker solange aus dem PC gelassen habe, bis Windows hochgefahren ist.
Bei Versuchen mit dauerhaft eingestecktem Netzwerkkabel konnte ich kein Netzlaufwerk mehr verbinden, da Windows bereits beim Hochfahren die vorhandenen Netzlaufwerke verbinden wollte und sich da schon verklemmt hatte.

Es tritt also ein Mix von Usern auf. Den, den man gewöhnlich kennt und eingibt ("Ich"), und ein zweiter, der wohl im Protokoll der Verbindungsherstellung vom Server zum Client gelangt ("nas\Ich").
Wenn ich nur das Netzlaufwerk S: angelegt habe, tritt kein Problem auf. Es gibt dann ja auch keinen Mix von Usern.

Jetzt verstehe ich auch das Funktionieren des Workarounds, alle Netzverbindungen zu trennen und neu anzulegen. Dann werden alle unter dem gleichen User angelegt und es funktioniert wieder bis zum nächsten Neustart.

Bei mir ist es also kein Problem mit SmB sondern ein Verbindungsproblem mit unterschiedlichen Usern zum gleichen Server.

Werde wohl damit leben können, beim Anmelden den aufgezwungenen User "nas\Ich" einzugeben ?!?!?!

Kannst Du das NAS nicht in die Domäne einbinden? Dann solltest Du die Zugriffsrechte auch auf dem NAS anpassen können.

🖖

Danke für den Hinweis, aber ich möchte für mein kleines Heimnetzwerk keine Domäne einrichten.

Bin jetzt etwas weiter.
Habe untersucht, warum jeweils eins meiner gemappten Laufwerke im Anmeldefenster den User vorgibt.
Der Unterschied besteht darin, ob man am Server angemeldet ist oder nicht, wenn ein neues Laufwerk gemappt wird.
Wird im nicht angemeldeten Zustand ein Netzlaufwerk angelegt, wird bei mir der User "nas\Ich" gespeichert. Damit bin ich dann am Server angemeldet. Wird jetzt ein weiteres Netzlaufwerk angelegt, wird als User nichts ( kann ja später beim Anmelden frei eingeben) oder "Ich" gespeichert.
Damit tritt nach dem Neustart das Problem auf, dass die Laufwerke mit unterschiedlichen Usern angemeldet werden, was dann zum Fehler führt: "... Mehrfache Verbindungen zu einem Server...".
Habe dann nach einem Neustart ohne Verbindung zum Server nur 1 Netzlaufwerk angelegt und wieder neu gestartet. Damit wurde zu jedem Laufwerk der gleiche User "nas\Ich" gespeichert.

Aktuell sehe ich jetzt nach mehreren Neustarts keinen Fehler mehr.
Würde wahrscheinlich auch andersherum funktionieren, indem man zusieht, alle Netzlaufwerke nur im verbundenen Zustand zu mappen. Sollte ich mal ausprobieren.

German Question Windows 10 Microsoft

Hotly discussed

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment