Hallo, nach Start von W11 sollen die Netzlaufwerke mittels eines Batchjobs gemountet werden. Dies klappt jedoch erst beim 2. bzw. 3. Start und ist deswegen extrem nervig. Geräte: NAS Synology DS220+ Router FritzBox 7590 PC HP Elitedesk 800 Zur Batchdatei: Speicherort: C:\Users\chris\AppData\Roaming\Microsoft\Windows\Startmenü \Programme\Autostart Inhalt: @echo off net use * /delete /yes net use E: \\DS220\Daten /user:LAB Passwort net use F: \\DS220\Grafik /user:LAB Passwort net use G: \\DS220\Applikationen /user:LAB Passwort net use H: \\DS220\Dokumentation /user:LAB Passwort net use I: \\DS220\photo /user:LAB Passwort net use J: \\DS220\music /user:LAB Passwort net use K: \\DS220\video /user:LAB Passwort net use L: \\DS220\Tech /user:LAB Passwort exit Fehleranzeige Win11: Es sind keine Einträge in der Liste. Systemfehler 85 aufgetreten. Der lokale Gerätename wird bereits verwendet. Frage nun: was mache ich hier falsch? Hat jemand dafür eine Erklärung ? Vielen Dank schon mal für hilfreiche Tips. CMX
Wenn du sie nicht automatisch beim Start mounten willst, dann häng ein /persistent:no an den net use.
Vielleicht wird Deine Batchdatei zu früh aufgerufen, zu einem Zeitpunkt, wo der Netzwerkstack noch nicht vollständig verfügbar ist? Um den Anschein schnellen Bootens zu erzeugen, stellt Windows durchaus schon den Desktop dar, wenn das unterliegende Geraffel noch damit beschäftigt ist, in die Pötte zu kommen. Bau da mal einfach das hier vor die "net use"-Zeilen ein: ping ds220 Das macht im Sekundentakt vier Ping-Versuche, verzögert also die Ausführung um vier Sekunden. Möchtest Du zehn Sekunden warten, mach da ein ping ds220 -n 10 draus. Wenn Du übrigens Deine Verbindungen mit dem Parameter /persistent anlegst, musst Du sie nicht ständig wiederherstellen. Daß es nicht die beste aller Ideen ist, ein Passwort im Klartext in einer Batchdatei stehen zu haben, sollte Dir klar sein. Wenn Du das bei Dir zu Hause machst, ist es natürlich harmlos, aber sowas sollte man sich andernorts bloß nicht angewöhnen.
Christoph M. schrieb: > Hat jemand dafür eine Erklärung ? Die lange Version von A.K.s Lösung: Bei der Benutzung von 'net use' legt Windows ein Laufwerk an und versucht es beim nächsten Start wieder zu verbinden. Das klappt aber meist nicht, weil das Netzwerk noch nicht bereit ist wenn das versucht wird (das Problem gibt es seit Windows 7 und man findet viele mehr oder weniger nicht funktionierende Tricks dagegen) aber der Laufwerksbuchstabe wird belegt. Der Schalter '/persistent:no' beim 'net use' verhindert jetzt, daß das Laufwerk beim Start wieder automatisch verbunden wird und wenn die Batch dann aufgerufen wird ist das Netzwerk bereit und der Buchstabe frei.
Oliver R. schrieb: > Bei der Benutzung von 'net use' legt Windows ein Laufwerk an und > versucht es beim nächsten Start wieder zu verbinden. Das tut es eigentlich nur, wenn /persistent bzw. /persistent:yes explizit angegeben wird. Oder haben die Pappnasen das Defaultverhalten in letzter Zeit geändert?
Harald K. schrieb: > Wenn Du übrigens Deine Verbindungen mit dem Parameter /persistent > anlegst, musst Du sie nicht ständig wiederherstellen. > > Daß es nicht die beste aller Ideen ist, ein Passwort im Klartext in > einer Batchdatei stehen zu haben, sollte Dir klar sein. Ganz genau. Sowohl wegen der Performance als auch wegen der Sicherheit ist es viel besser, die Dinger einmal manuell persistent anzulegen. Das Problem der späteren Verfügbarkeit kann man z.B. durch Warten erschlagen, wie von dir gezeigt z.B. mittels ping. Allerdings ist das nicht die beste Lösung. Denn, genau genommen, sagt ein erfolgreiches ping leider noch nichts über die Verfügbarkeit des Shares aus. Gerade bei den Synologies sogar fast garnix. Wenn die ein fettes RAID und einen Haufen Dienste hochzufahren haben, können da gerne mal einige Dutzend Sekunden zwischen der ersten Antwort auf ping und der tatsächlichen Verfügbarkeit der Shares liegen. Die Lösung mit dem ping ist also bestenfalls nur dafür geeignet, das clientseitige Verhalten zu kompensieren, nicht aber das Verhalten des Servers. Nicht jeder lässt seine Syno 24/7 durchlaufen... Viel besser ist deshalb, sich per Setup-API in's System einzuklinken und sich darüber über das Erscheinen von Volumes informieren zu lassen, statt darauf zu warten. Leider bietet die Kommandozeile sowas nicht. Man muss ein kleines Tool schreiben, welches das erledigt.
Harald K. schrieb: > Vielleicht wird Deine Batchdatei zu früh aufgerufen Dafür hat Windows eine Lösung: Systemsteuerung/Verwaltung/Aufgabenplanung/Aufgabe erstellen Trigger: Beim Start, Verzögern 1 Minute (oder andere Zeitangabe) Mit "Wiederholen" kann man auch das Problem erschlagen, dass der Server erst "viel" später oder nie erreichbar ist. Mit Trigger "Bei einem Ereignis" kann man vielleicht auch das Ereignis "Netzlaufwerk verfügbar" o. Ä. ausnutzen. Habe ich aber nicht probiert.
:
Bearbeitet durch User
Ob S. schrieb: > Die Lösung mit dem ping ist also bestenfalls nur dafür geeignet, das > clientseitige Verhalten zu kompensieren, nicht aber das Verhalten des > Servers. Nicht jeder lässt seine Syno 24/7 durchlaufen... D'accord. Aber hier gehts um den Client. Christoph M. schrieb: > nach Start von W11 sollen die Netzlaufwerke mittels eines Batchjobs > gemountet werden. Du musst also keine andere Baustelle eröffnen.
Harald K. schrieb: > Oder haben die Pappnasen das Defaultverhalten in letzter Zeit geändert? Ist etwas komplizierter, weil es laut Doku kein klares Defaultverhalten gibt, sondern die Kiste sich das merkt. In Scripts ist es jedenfalls sicherer, explizit hinzuschreiben, ob man persistent oder nichtpersistent meint. Und schon aus alter Gewohnheit würde ich zwischen net use /delete und Neuverbindung ein paar Sekunden legen.
:
Bearbeitet durch User
Warum trägt man die Laufwerke nicht einmal per "persistent:yes" ein und lässt die Batchdatei dann links liegen, weil Windows die Shares automatisch wieder beim nächsten Start verbindet? Noch einfacher kann man per Klickibunti im Explorer einfach die Verbindung auf einen Buchstaben machen, dann brauchts gar keine Batchdatei... Zumindest bei meinen QNAPs funktioniert das einwandfiffi!
Jens M. schrieb: > Warum trägt man die Laufwerke nicht einmal per "persistent:yes" ein und > lässt die Batchdatei dann links liegen, weil Windows die Shares > automatisch wieder beim nächsten Start verbindet? Mein Gott, du bist so eingeschränkt, dass du nichtmal das primäre Anliegen begriffen hast: es ging vor allem darum, bei Verfügbarwerden der Volumes etwas zu starten (hier: ein Backup auf eben diese Volumes).
Ob S. schrieb: > Mein Gott, du bist so eingeschränkt, dass du nichtmal das primäre > Anliegen begriffen hast Da hast du dich aber mal ganz grob verschätzt, mein liebster. Es geht darum, Netzlaufwerke zu verbinden, und warum das in einer Batchdatei im Autostart nicht geht. Komischerweise geht's, wenn man DOS hinter sich lässt und Windows den vorgesehenen Weg gehen lässt die Shares selber zu verbinden, wenn es denn Zeit dazu hat. Was nach der Ausführung der Batchdatei ist, weswegen die fehlschlägt. Das deine falschen Vermutungen überhaupt genau gar nix mit dem Thread und der Frage zu tun hatten, und du außer heißer Luft auch keine Lösung angegeben hast, lässt vermuten das der Eingeschränkte in diesem Fall du selber bist.
Ob S. schrieb: > es ging vor allem darum, bei Verfügbarwerden > der Volumes etwas zu starten (hier: ein Backup auf eben diese Volumes). Dir vielleicht, dem Threadstarter nicht.
Rolf schrieb: > Mit Trigger "Bei einem Ereignis" kann man vielleicht auch das Ereignis > "Netzlaufwerk verfügbar" o. Ä. ausnutzen. Habe ich aber nicht probiert. Genau die richtige Ecke. Mein W10-Laptop soll beim Start drei Dateien per UNC-Pfad holen, in einer Batch per xcopy /D. Im Autostart geht das schief, per Aufgabenplaner "wenn Netz verfügbar" läuft das stabil. (prx) A. K. schrieb: > Und schon aus alter Gewohnheit würde ich zwischen net use /delete und > Neuverbindung ein paar Sekunden legen. Besser generell mit persistant:no mounten. Was mir auch nicht gefällt, sind die Passworte in der Batch. Man legt am Server den Benutzer passend an, ggfs. beschränkt auf bestimmte Verzeichnisse und braucht es dann nicht zu übergeben. Jens M. schrieb: > Warum trägt man die Laufwerke nicht einmal per "persistent:yes" ein und > lässt die Batchdatei dann links liegen, weil Windows die Shares > automatisch wieder beim nächsten Start verbindet? Das ist unklug, weil der Windows-Explorer dann ewig lange in Timeouts herumdödelt, wenn ein Netzlaufwerk nicht verfügbar ist.
> Genau die richtige Ecke. Mein W10-Laptop soll beim Start drei Dateien > per UNC-Pfad holen, in einer Batch per xcopy /D. Im Autostart geht das > schief, per Aufgabenplaner "wenn Netz verfügbar" läuft das stabil. Welche Seiteneffekte das hat, weiss man aber auch nicht. Von Windows bereitgestellte SMB-Shares sind inhaerent unzuverlaessig. Meine "portablen" Rechner holen sich sowas von einem TFTP-Server. :) Wenn bei dem ein "Ping" erfolgreich ist, steht auch der Service zur Verfuegung. > Besser generell mit persistant:no mounten. +++ Seit ich Windows kenne, ist persisten:yes wohl der (schlechte) Default. Den brauchen eigentlich nur Hausfrauen und DAUs. > Das ist unklug, weil der Windows-Explorer dann ewig lange in Timeouts > herumdödelt, wenn ein Netzlaufwerk nicht verfügbar ist. Wenn es "nur" der Explorer waere, ... dann waere es mir herzlich egal. Aber alle Operationen auf Dateien sind betroffen. Es gibt uebrigens einen ueberraschend einfachen Trick, um Netzlaufwerke ohne Passworteingabe zu mounten. Man muss sich gegenueber dem anderen System naemlich nur einmal authentisieren... Diese Authentisierung wird dann auch fuer folgende Operationen benutzt. Und dabei hilft dann die Persistenz...
Manfred P. schrieb: > Das ist unklug, weil der Windows-Explorer dann ewig lange in Timeouts > herumdödelt, wenn ein Netzlaufwerk nicht verfügbar ist. Und das wäre anders, wenn man im Autostart eine Batch startet, die die Shares mit persistent:no mountet? Die bleibt dann auch ewig stehen, erwartet Eingaben und wirft so lustige Fehler wie "Systemfehler: 59" o.ä. Ja, das hätte man besser machen können, aber hat MS nunmal nicht. Motopick schrieb: > Seit ich Windows kenne, ist persisten:yes wohl der (schlechte) Default. > Den brauchen eigentlich nur Hausfrauen und DAUs. Bash Bash Bash. Wie geht es denn anders? Wenn der DC Freigaben "fernmountet" ist das genau so in der Registry eingetragen wie mit persistent:yes. Das ist nunmal der bei Windows vorgesehene Weg, und er funktioniert tadellos, sofern die Freigaben verfügbar sind. Wenn sie es nicht sind, versagen aber auch alle anderen Methoden, und den SMB als inhärent unzuverlässig zu bezeichnen ist wagemutig, wenn es die einzige frickelfreie Lösung ist. Das sie Millionenfach einwandfrei klappt kommt noch oben drauf. Jaja, der Profi nutzt Linux-Server und Workstations und bindet seine Netzlaufwerke als TFTP ein, ich weiß. Was passiert denn da, wenn der ICMP-Agent läuft, der TFTPd aber nicht? Klappt auch nicht, oder?
> und bindet seine Netzlaufwerke als TFTP ein
Du hast wirklich keine Ahnung.
Fuer Netzlaufwerke benutze ich ganz ueberwiegend NFS.
Aber es ist halt unzweckmaessig, fuer einen "portabel" genutzten
Rechner, dann nicht vorhandene Netzlaufwerke mutzuschleppen.
NFS muss sowohl auf dem Syno als auch unter Windows erstmal nachinstalliert werden. SMB ist (nicht nur) unter Windows verbreiteter und tut es out of the box. Ob das so viel besser ist...
> NFS muss sowohl auf dem Syno als auch unter Windows erstmal > nachinstalliert werden. Ein NAS auf dem NFS erst nachinstalliert werden muss? Das ist ja mal eine harte Nummer. Unter Windows geht das seit XP mit jeder Version immer einfacher. Wenn es eine Pro/Enterprise-Version ist. Unter Unix/Linux ist es ohnehin nahezu immer verfuegbar. Und das sowohl als Server als auch als Client.
P.S.:
> SMB ist (nicht nur) unter Windows verbreiteter und tut es out of the box.
Da koennte ich leicht auch gegenteiliges behaupten, wenn man z.B.
unterschiedliche Windowsversionen im Einsatz hat, oder mehr oder
weniger antike Geraetschaften (weiter) benutzen will. Dann ist es
mit dem O.O.B.-Erlebnis naemlich nicht mehr soweit her.
Motopick schrieb: > wenn man z.B. > unterschiedliche Windowsversionen im Einsatz hat Welche Windows-Version kennt kein SMB?
Motopick schrieb: > Ein NAS auf dem NFS erst nachinstalliert werden muss? Oma Gugel behauptet, das NFS (wenn es überhaupt unterstützt wird von der Syno- und QNAP-Firmware) "aktiviert" werden muss. Man muss also irgendwo in den Systemeinstellungen ein Häkchen setzen, und dann werden vmtl. irgendwelche Dienste aktiviert usw. Ist jetzt nicht "Datei herunterladen und installieren", aber OoB tut es eben auch nicht. Bei Windows ist es ebenso: Irgendwo im Systemmanager ein Kreuzchen machen, dann wird was nachinstalliert, und dann kann man es nutzen. Da wird definitiv was ins System eingebaut, das nur als Archiv an Board ist bei der Installation. Motopick schrieb: > wenn man z.B. > unterschiedliche Windowsversionen im Einsatz hat, oder mehr oder > weniger antike Geraetschaften (weiter) benutzen will. Da kenne ich nur das Problem, das neue Windosen bitte gerne ein neueres SMB nutzen wollen, während alte das noch nicht können. Aber wir reden da von 20 Jahren und mehr dazwischen, irgendwo muss man da auch mal einen Cut machen. Aber bitte welche antiken Geräte nutzen NFS und können kein SMB? Sollte der Hinweis der auf so manchem Google-Ergebnis zu NFS auftaucht berechtigt sein, das es hier und da als antiquiert angesehen wird und SMB der Nachfolger sei? Dann wäre das aber ein reichlich konstruierter Spezialfall... Oder?
> und SMB der Nachfolger sei
An der Stelle musste ich nun wirklich lachen.
Nuex fuer ungut. :)
Der Rest stimmt wohl einigermassen.
Ich habe evtl. einfach nur traditionell mehr Systeme die
NFS sowieso koennen, als die neu hinzugekommenen Systeme.
Also muessen die sich nach dem richten was schon da ist.
Das M$ es in ihren "professionellen" Systemen als einfach zu
installierendes Addon aufgenommen hat, zeigt ja den Bedarf.
Und fuer strunzdumme "Home"-Versionen, gibt es hier tatsaechlich
auch noch einen SMB-Server. Den starte ich aber eben nur bei
Bedarf. Also eher gaaaaaanz selten.
Meine "portablen" Systeme testen beim Systemstart uebrigens
ob sie "zu Hause" sind. Und wenn ja werden die NFS-Shares gemountet.
Sonst nicht. Das sollte eigentlich jeder mit etwas Restintelligenz
hinbekommen und funktioniert fuer SMB-Mounts natuerlich auch.
Motopick schrieb: >> Besser generell mit persistant:no mounten. > +++ > Seit ich Windows kenne, ist persisten:yes wohl der (schlechte) Default. > Den brauchen eigentlich nur Hausfrauen und DAUs. Ob die in der Lage sind, "net use ..." einzutippen? >> Das ist unklug, weil der Windows-Explorer dann ewig lange in Timeouts >> herumdödelt, wenn ein Netzlaufwerk nicht verfügbar ist. > Wenn es "nur" der Explorer waere, ... dann waere es mir herzlich egal. > Aber alle Operationen auf Dateien sind betroffen. Habe ich nie im Detail untersucht, aber wir sind uns einig, dass man damit das System ungewollt ausbremst. > Es gibt uebrigens einen ueberraschend einfachen Trick, um Netzlaufwerke > ohne Passworteingabe zu mounten. Ja: Man legt im Zielsystem den Benutzer an, mit dem der Client gestartet wird. Ich mounte Windows-Shares, ohne das Passwort eingeben zu müssen. Jens M. schrieb: >> Das ist unklug, weil der Windows-Explorer dann ewig lange in Timeouts >> herumdödelt, wenn ein Netzlaufwerk nicht verfügbar ist. > Und das wäre anders, wenn man im Autostart eine Batch startet, die die > Shares mit persistent:no mountet? > Die bleibt dann auch ewig stehen, erwartet Eingaben und wirft so lustige > Fehler wie "Systemfehler: 59" o.ä. Wenn die Batch die Netzlaufwerke nicht verbinden kann, hängt sie eine Weile in den Timeouts. Aber danch ist Ruhe, während persistent bekannte Shares immer wieder vom Explorer gesucht werden und die Kiste ausbremsen. Jens M. schrieb: > Motopick schrieb: >> Seit ich Windows kenne, ist persisten:yes wohl der (schlechte) Default. >> Den brauchen eigentlich nur Hausfrauen und DAUs. > Bash Bash Bash. > Wie geht es denn anders? > Wenn der DC Freigaben "fernmountet" ist das genau so in der Registry > eingetragen wie mit persistent:yes. Wer macht hier "Bash Bash Bash." - Motopick jedenfalls nicht, der kennt das Verhalten, welches kalkulierbar und sinnvoll nutzbar ist.
Moin und herzliche Grüße und ein kräftiges Dankeschön an Alle, die hier
geantwortet haben!!!
Tja, und nun...?
Ich werde die Ideen von Euch mal testen. Mal sehen, was geht.
Nochmals DANKE !!!
PS: An die Adresse von Harald K.: Wer sagt denn dass das angegebene
Passwort
auch das richtige ist...? ;-)
Ist nur ein Platzhalter.
:
Bearbeitet durch User
Christoph M. schrieb: > PS: An die Adresse von Harald K.: Wer sagt denn dass das angegebene > Passwort auch das richtige ist...? Es geht nicht darum, welches Passwort hier im Forum steht, sondern um das in Deiner Batchdatei. Daß Du in der einen "Platzhalter" unterbringst, ist eher unwahrscheinlich, denn dann würde Deine Batchdatei nicht funktionieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.