[gelöst] Opsi Sambafreigabe Fehler 53

[andré]

Hi,
ich habe seit einigen Wochen ein kleines Problem mit Opsi. Und zwar lasse ich bei einer Neuinstallation das Windows Offline Update drüber laufen. Dazu habe ich auf dem Opsi-Server eine Freigabe namens offlineupdate erstellt, die ich in dem Opsipaket mittels net use einbinde.

Das Problem:
Das Einbinden der Freigabe bricht meistens mit der Fehlermeldung

Code: Alles auswählen

[5] [Apr 25 19:44:18:352] [offlineupdate] DosInAnIcon_Netzlaufwerk
[6] [Apr 25 19:44:18:352] [offlineupdate]   c:\opsi.org\tmp\_opsiscript_Jf18Jr92.cmd saved back with encoding: system
[6] [Apr 25 19:44:18:352] [offlineupdate]   Executing "cmd.exe" /C c:\opsi.org\tmp\_opsiscript_Jf18Jr92.cmd
[6] [Apr 25 19:45:05:366] [offlineupdate]   ExitCode 2
[6] [Apr 25 19:45:05:366] [offlineupdate]               
[6] [Apr 25 19:45:05:366] [offlineupdate]               output:
[6] [Apr 25 19:45:05:366] [offlineupdate]               --------------
[6] [Apr 25 19:45:05:367] [offlineupdate]               
[6] [Apr 25 19:45:05:367] [offlineupdate]               C:\Windows\system32>net use X: \\172.16.0.30\offlineupdate /persistent:no 
[6] [Apr 25 19:45:05:367] [offlineupdate]               Systemfehler 53 aufgetreten.
[6] [Apr 25 19:45:05:367] [offlineupdate]               
[6] [Apr 25 19:45:05:367] [offlineupdate]               Der Netzwerkpfad wurde nicht gefunden.

ab.

Das Merkwürdige daran ist, dass die Freigabe an sich funktioniert. Das Offlineupdate-Paket darf 10 mal neustarten, bis es erfolglos abbricht und bei den ersten zwei Neustarts funktioniert das Einbinden einwandfrei. Manchmal ab dem dritten, meistens ab dem vierten Neustart geht das nicht mehr.

Die opsi_depot-Freigabe wird logischerweise erfolgreich eingebunden, es gibt insofern kein Problem mit der Verbindung zum Server. Beim Shutdown und on_demand funktioniert das Einbinden der Freigabe über das offlineupdate-Paket immer. Ich muss nach einem erfolglosen Versuch nur das Netzwerkkabel ziehen, lasse nach dem Neustart Opsi den Timeout herunterzählen, stecke das Kabel wieder an und führe das Paket on_demand aus und es funktioniert einwandfrei.

Bisherige Lösungsversuche:

• - Erster Gedanke: DNS-Problem. Daher habe ich testweise die IP-Adresse fest hinterlegt. Hat nicht geholfen
  - Netzwerkkarten-Problem war mein zweiter Gedanke. Dagegen spricht, dass die Verbindung zum Depot funktioniert. Trotzdem habe ich testweise mittels sleepseconds 60 vor dem Verbinden das Skript warten lassen, hat nicht geholfen.
  - Eine Problembeschreibung im Netz wies darauf hin, dass IPv6 das Problem sein könnte. Habe ich deaktiviert, hat nicht geholfen.
  - Die LAN Manager-Authentifizierungsebene habe ich testweise auf "LM- und NTLM-Antworten senden" geändert, hat nicht geholfen
  - Es gibt keine mitgeloggten Fehler vom Samba-Server, daher schließe ich mal aus, dass der Fehler dort zu suchen ist.

Das Paket hat vor einigen Wochen noch korrekt funktioniert. Was mich dabei halt extrem irritiert ist, dass die Verbindung an sich funktioniert und erst nach einigen Versuchen und NUR beim automatischen Start von Opsi nicht mehr geht. Ich habe ein anderes Paket, das auf eine zweite von mir auf dem Opsi-Server erstellte-Freigabe schreibt und das macht gar keine Probleme. Beide Freigaben sind bis auf "writeable" gleich eingerichtet.

Die Einstellungen der Freigabe:

Code: Alles auswählen

[offlineupdate]
   available = yes
   comment = WSUS Offline Update Daten
   path = /var/lib/offlineupdate
   writeable = no
   browseable = no
   public = no
   invalid users = root

Opsi-und Sambaversion:

Code: Alles auswählen

root@opsi:~# dpkg -l |grep samba
ii  python-samba                     2:4.2.14+dfsg-0+deb8u5        amd64        Python bindings for Samba
ii  samba                            2:4.2.14+dfsg-0+deb8u5        amd64        SMB/CIFS file, print, and login server for Unix
ii  samba-common                     2:4.2.14+dfsg-0+deb8u5        all          common files used by both the Samba server and client
ii  samba-common-bin                 2:4.2.14+dfsg-0+deb8u5        amd64        Samba common files used by both the server and the client
ii  samba-doc                        2:4.2.14+dfsg-0+deb8u5        all          Samba documentation
ii  samba-dsdb-modules               2:4.2.14+dfsg-0+deb8u5        amd64        Samba Directory Services Database
ii  samba-libs:amd64                 2:4.2.14+dfsg-0+deb8u5        amd64        Samba core libraries
ii  samba-vfs-modules                2:4.2.14+dfsg-0+deb8u5        amd64        Samba Virtual FileSystem plugins


root@opsi:~# dpkg -l |grep opsi
ii  opsi-atftpd                      0.7.dfsg-6                    amd64        advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                    4.0.7.1.3-1                   all          OPSI config editor
ii  opsi-depotserver                 4.0.6.7-2                     all          opsi depotserver configuration package
ii  opsi-linux-bootimage             20170206-1                    amd64        opsi bootimage for netboot tasks.
ii  opsi-utils                       4.0.7.7-3                     all          utilites for working with opsi.
ii  opsiconfd                        4.0.7.4.1-1                   all          opsi configuration service
ii  opsipxeconfd                     4.0.7.5-3                     all          opsi pxe configuration daemon
ii  python-opsi                      4.0.7.28-5                    all          opsi python library

Hat noch jemand eine Idee, woran das liegen könnte?

[ueluekmen]

Hi,

ich würde erst mal auf Berechtigung tippen. Es kann aber auch was ganz blödes wie Netzwerkkartentreiber sein. Das will ich nicht ausschliessen. Die Frage ist aber, warum machst du einen eigenen Share? Warum nicht einfach als opsi-Paket bauen? Dann landet das auch im Depot-Share. Man könnte entweder das Skript direkt in das Paket packen, man kann aber auch ein Script-Paket dazu bauen und dann folgendes im opsiscript machen:

Code: Alles auswählen

%ScriptPath%\..\wsusofflineupdate\.

Ich gebe aber zu, ich habe die Beschreibung nicht komplett verstanden

[andré]

Danke erstmal für die Antwort.

Das wsusoffline-Skript (http://download.wsusoffline.net/) wird jede Woche per Cron ausgeführt, um aktuelle Updates zu ziehen. Das OPSI-Skript führt dann immer nur die Setup.exe im Share aus, und kann auf diese Weise immer die aktuellsten Updates installieren, ohne dass ich das OPSI-Skript anfassen muss.

Das merkwürdige ist halt, dass nur OPSI Probleme hat, dieses Share zu verbinden, nachdem Windows mehrere Male neugestartet wurde. Und das auch nur beim Bootvorgang.

Edit: Was hast du denn nicht verstanden? Die entsprechenden Abschnitte kann ich auch gerne anders erklären.

[uncle_scrooge]

Bau' vor dem net use testweise mal eine längere Pause ein (ping 127.0.0.1 -n 60 > nul ergibt eine Minute) und/oder prüf' vorher, ob der TCP/IP-Stack und das SMB-Geraffel auch wirklich schon da sind.
Das riecht nach einem Timingproblem.

[andré]

Timeout habe ich mittels sleepseconds 60 schon probiert, das hat nicht geholfen.
Und die Freigabe Opsi_depot, die sich auf dem selben Server befindet, wurde ja schon erfolgreich verbunden.

[ueluekmen]

Hi,

ich gestehe, dass ich nicht jedes Posting komplett lese und weil wir ständig unter Strom stehen entgeht mir auch gerne das ein oder andere. Hat dieser Share die selbe Berechtigung wie opsi_depot? Das ist wichtig, weil es sonst Berechtigungsprobleme geben kann. Aber 53 heißt, gibt es nicht. Bei einem Berechtigungsproblem sehe das anders aus.

Da bleibt wirklich nur, samba auf debug stellen und analysieren. Das macht aber nicht wirklich spaß. Wenn die Requests beim samba-Server ankommen auf der Serverseite suchen, wenn die Requests nicht ankommen auf der Clientseite suchen.

Ein Supportvertrag von uib hilft auch bei solchen Fragen.

Das OPSI-Skript führt dann immer nur die Setup.exe im Share aus, und kann auf diese Weise immer die aktuellsten Updates installieren, ohne dass ich das OPSI-Skript anfassen muss.

Dennoch schliesst das aus meiner Sicht nicht die Möglichkeit aus alles aus dem opsi_depot-Share zu bedienen. Die Antwort dazu habe ich dir schon verraten

[uncle_scrooge]

Asche über mein Haupt. Dein sleepseconds habe ich überlesen.
Du bist sicher, daß Dein Depot share zu diesem Zeitpunkt verbunden ist? (Ich hab' da so meine Zweifel.) Ein fröhliches dir p: vor dem net use sollte dann was zurückliefern.

Ansonsten kann ich Hr Ülükmen nur beipflichten.
Wenn wirklich was am Server ankommt, Samba debuggen.
Ggfs. Netzwerkverkehr mitschneiden.
Und, auch wenn wir selber keinen haben, unterstütze ich den Hinweis auf einen Supportvertrag. Ohne genauere Kenntnis Deiner Umgebung inkl. des ominösen Skriptes wird sichhier im Forum wohl jeder schwer tun, Sinnstiftendes zu sagen. Merkst Du ja an meinem eigenen Gebrabbel.

[andré]

hm, ok, das habe ich noch nicht gemacht. teste ich morgen mal.

[andré]

Dennoch schliesst das aus meiner Sicht nicht die Möglichkeit aus alles aus dem opsi_depot-Share zu bedienen. Die Antwort dazu habe ich dir schon verraten

Gut, da muss ich mal schauen, wie und ob das Handling besser läuft, wenn ich das direkt ins Depot werfe. Danke für die Anregung.

[andré]

dir P: hat ergeben, dass das Depot vorhanden ist, wenn der Fehler auftaucht.
Ich habe da jetzt kurzen Prozess gemacht und das doch mit auf das depot gelegt, damit funktioniert die Installation wieder.

Ist halt nur schade, dass es auf einmal nicht mehr wie gewünscht funktioniert hat. Das depot liegt auf einem extra-device, was ich nicht unnötig vergrößern wollte. Die offlineupdate-Dateien lagen wiederum auf einem Device, was direkt unter root gemountet war und genügend Speicher hatte. Den Speicher habe ich jetzt ein wenig umhergeschoben, damit das passt, da hoffe ich jetzt mal, dass ich zukünftig von diesem Problem verschont bleibe.