Das System kann die angegebene Datei nicht finden

[conquestador]

Hallo Community,

ich habe das Problem, dass die Installation in den Zweigstellen fehlschlägt, weil OPSI das InstallFile nicht findet, obwohl es da ist und über UNC von überall aufgerufen werden kann.
Um in den Standorten die (größeren) Installfiles nicht erst über das VPN ziehen zu müssen (ich habe nur einen Depotserver in der Zentrale), habe ich an jedem Standort auf Rechnern vor Ort jeweils eine Opsi-Freigabe erstellt. System hat Vollzugriff.
Über das Script lese ich das Standardgateway des Rechners aus, der installieren soll und selektiere so den Standort, wodurch ich dann das $InstallFileDir$ definiere.
Wenn ich jetzt die Installation auf dem PC mit der Freigabe anstoße, funktioniert alles. Wenn ich jedoch einen anderen PC installieren will, findet er die Datei nicht.
Ich vermutete den Fehler in dern Berechtigungen und habe testweise die Freigabe für "jeder" auf Vollzugriff gesetzt, leider ohne Erfolg.

Hat jemand eine Idee, was ich falsch mache?

[conquestador]

Jetzt wird es noch interessanter:
Ich habe mal auf DosInAnIcon umgebaut, um das InstallFile aus der Freigabe nach local zu kopieren und local auszuführen.
Jetzt sagt er mir, dass er die CMD als Invoker SYSTEM startet. Dann kommt diese Fehlermeldung:

Code: Alles auswählen

C:\WINDOWS\system32>copy \\10.20.10.2\OPSI-Freigabe\Java\jre-8u301-windows-x64.exe c:\opsitemp
Der Benutzername oder das Kennwort ist falsch

Welche login-Daten??, wozu braucht er das als SYSTEM, wo doch testweise sogar "jeder" Vollzugriff hat ???
Als einfacher Domänen-User kann ich den Befehl erfolgreich in der CMD absetzen...

Ich versteh's nicht!

[mattiasmab]

Auch wenn das etwas stark gegen das System arbeiten zu sein scheint, hätte folgende Vorschläge:

• Prüfe auch die Dateisystem-Rechte und nicht nur die der Freigabe
• Falls es sich dabei um ein DFS-Share handelt, ist eine Verbindung so im Kontext von SYSTEM nicht möglich
  In dem Fall auf den eigentlichen Knoten im UNC verweisen (also gibt es einen Reiter "DFS" wenn man auf die Eigenschaften eines testweise Verbundenen Netzlaufwerks geht? Wenn ja, dann den aktiven Pfad nutzen. Ist irgendeine Einschränkung von Windows, die ich noch nicht wirklich verstanden habe. Hat angeblich mit dem DoubleHob zu tun, was aber keinen Sinn ergibt...)
• Ist die Anmeldung überhaupt anonym erlaubt? SYSTEM hat keine Credentials (wie ein angemeldeter Nutzer), die zum Server geschickt würden. In dem Fall ansonsten einen Verbindungs-Benutzer alla pcpatch erzeugen und vorher per `net use \\...\IPC$ "pwd" /user:pcpatch_whatever` verbinden.

[conquestador]

Es handelt sich um eine "normale" Windows-Freigabe auf einem NTFS. Nicht nur die Freigabe ist für jeden zugreifbar sondern auch unter Sicherheit hat testweise "jeder" Vollzugriff. Das Kuriose ist, in der selben Freigabe fiegt das Installfile für Firefox. Diese Installation funktioniert, allerdings handelt es sich dabei un eine .msi, die Installationen von anderen exen funktionieren auch nicht.

[Jan.Schmidt]

Was bedeutet Vollzugriff?

Derjenige welcher darf auch anderen Rechte vergeben, nicht nur ändern.

Vollzugriff ist also schonmal ganz sicher ein Hinweis das da etwas nicht so läuft, wie es sein sollte,

Dann muß man ein net use \\bla\bub /user:domain\readonlyuser passwort irendwo hinterlegen - wenn man so nen driet baut.

Dann gibt es gpos die zb sagen können eine exe auf einem server ist unsicher, eine msi nicht.

So ganz allgemein würde ich sagen, die Fragestellung gehört in die Zigarettenpause bei einer MCSE oder A Schulung nicht in ein opsi Forum.

[conquestador]

@Jan.Schmidt
Das ist leider nicht Hilfreich.
Ich habe bei den Helfenden schon oft deinen Namen gelesen, ich schätze das sehr und bin für jede Hilfe dankbar. Allerdings solltest du dir solch arrogante Sätze mit "Zigarettenpause bei einer MCSE oder A Schulung" verkneifen. Wenn du nicht nur den letzen Eintrag angesehen hättest, wäre dir aufgefallen, dass der Vollzugriff nur Testweise ist.
Da ich von überall und mit jedem User auf die Freigabe zugreifen kann, jedoch nicht während einer Installation mit OPSI, bin ich schon der Meinung, dass meine Frage in diesem Forum durchaus richtig platziert ist.
Und nein, eine exe-verbietende GPO habe ich nicht...

[Jan.Schmidt]

Hi,

also dann anders...
Ich lese meistens ziemlich genau, aber bei Vollzugriff auch wenns nur Testweise ist - hört halt der Spass auf,
Wie ich geschrieben habe- das kann niemals die Lösung sein.

Mein Trick mit Hilfreich ist immer - gebe den Leuten Tipps - niemals nie nicht ein copy&paste denknichtdrübernach hautoo.
Das Hülft am Ende immer mehr, als das andere unter Hilfreich verstehen.

Arrogant mag sein, aber ich kenne viele - die sich beim Computer viel zutrauen - keiner davon (außer zwei die ich kenne) würde sich aber an ein Flugzeug rantrauen - denn da wissen die meisten, das dahinter eine jahrelange Ausbildung steckt. Di ahnst es die beiden sind gelernte Fluggerätmechaniker.

opsi wie so alle anderen Softwareinstallatöre auch installiert immer unter dem Benutzer System.
Dieser Benutzer System kann vieles und vieles nicht. Denn er ist ein lokaler "Benutzer"

Wenn du also mit System eine Freigabe nutzen willst, dann mußt du das Laufwerk vorher mit einem anderen - der am besten read only Zugriff hat verbinden.
Das ist aber im Zusammenhang mit OPSI "Murks".

Hast du dain den Zweigstellen irgendeine Möglichkeit eine Pizzabox mit Linux hinzustellen? Oder sogar eine Virtuelle Umgebung???

Wenn ja - baue dort OPSI Server auf - dann kannst du damit auch Betriebsysteme aufsetzen, das kannst du mit einer ntfs Freigabe alles nicht.

Zum Thema msi und exe
ein msi wird üblicherweise vom OS unter msiexec - das lokal auf dem Rechner ist - ausgeführt.
Eine Exe immer von da - wo Sie liegt.

[mattiasmab]

Es handelt sich um eine "normale" Windows-Freigabe auf einem NTFS. Nicht nur die Freigabe ist für jeden zugreifbar sondern auch unter Sicherheit hat testweise "jeder" Vollzugriff. Das Kuriose ist, in der selben Freigabe fiegt das Installfile für Firefox. Diese Installation funktioniert, allerdings handelt es sich dabei un eine .msi, die Installationen von anderen exen funktionieren auch nicht.

Hier kann ich dir gerade nicht ganz folgen. Also der selbe Befehl funktioniert um eine MSI von Firefox zu kopieren, aber nicht um eine EXE von JRE zu kopieren?
Die Anmerkung von Jan bzgl. des Ausführungsortes wären in dem Fall hinfällig, da der von dir gelistete Befehl schließlich ein Kopieren in ein Lokales Verzeichnis vornimmt. Somit hat dies nichts mit der Ausführung selbiger Datei zu tun und müsste - falls wirklich so - somit zunächst außer acht gelassen werden.

Ansonsten hätte ich weitere zwei Anmeldungen:

• Probiere die Befehle mal interaktiv mit einen System-Konsole. Dies geht sehr einfach mit PSEXEC von Sysinternals (nun Microsoft selbst). Dazu `psexec -s -i cmd.exe` - was passiert da?
• Wenn doch direkt vor Ort ausgeführt wird (anders kann ich mir den Unterschied zwischen MSI und EXE beim reinen Kopieren nicht erklären) kann zuvor folgende Umgebungsvariable gesetzt werden und/oder überprüft werden, ob ein Zone-Flag im NTFS-Stream angehangen ist (siehe unten) :

Code: Alles auswählen

## Powershell
# Disable Zone checking to prevent warnings when running executables
$env:SEE_MASK_NOZONECHECKS = 1
... call exe

## CMD
set SEE_MASK_NOZONECHECKS = 1
... call exe

Zone-Identifier entfernen:

Code: Alles auswählen

# POSH
Unblock-File ...Path\To\File.ext

# Cmd
echo.>File.ext:Zone.Identifier

Ein Kopieren von Daten haben wir zeitweise auch genutzt und hatten eigentlich keine Probleme, außer der erwähnten DFS. Ob von Windows/NTFS oder Linux/FS+Samba sollte dabei irrelevant sein, da CIFS das System dahinter schließlich eh versteckt.

[Jan.Schmidt]

Die Anmerkung von Jan bzgl. des Ausführungsortes wären in dem Fall hinfällig, da der von dir gelistete Befehl schließlich ein Kopieren in ein Lokales Verzeichnis vornimmt. Somit hat dies nichts mit der Ausführung selbiger Datei zu tun und müsste - falls wirklich so - somit zunächst außer acht gelassen werden.

Hi,

das Problem ist doch ein anderes...

Jetzt wird es noch interessanter:
Ich habe mal auf DosInAnIcon umgebaut, um das InstallFile aus der Freigabe nach local zu kopieren und local auszuführen.
Jetzt sagt er mir, dass er die CMD als Invoker SYSTEM startet. Dann kommt diese Fehlermeldung:

Code: Alles auswählen

C:\WINDOWS\system32>copy \\10.20.10.2\OPSI-Freigabe\Java\jre-8u301-windows-x64.exe c:\opsitemp
Der Benutzername oder das Kennwort ist falsch

Welche login-Daten??, wozu braucht er das als SYSTEM, wo doch testweise sogar "jeder" Vollzugriff hat ???
Als einfacher Domänen-User kann ich den Befehl erfolgreich in der CMD absetzen...

Ich versteh's nicht!

Zuerst hat er - wenn ich das richtig lese - nicht kopiert und nun kriegt er ein Der Benutzername oder das Kennwort ist falsch zurück.
Warum das so ist, habe ich ja geschrieben.

Aber du hast da einen weiteren bisher nicht beachteten Punkt beleuchtet.
Er hat das Zeugs auf nem NTFS Share und was hat ntfs mit irgendwelchen Installern gemeinsam?
Die kommen meistens auf dem Weltweitennetz und haben ein unsecure source flag, das "wir" üblicherweise immer ignorieren können, weil das Flag beim kopieren auf ein Linux system wie einen OPSI verloren geht.
Wenn das aber in einer NTFS Freigabe liegt bleibt es da, wenn es gesetzt ist.

Trotzdem ich vermute immer noch es liegt daran, das msiexec eine lokale ausführbare Datei ist und eine exe auf einem Share eben nicht.
Und wenn mann keine GPO gebaut hat, die besagt Server X und Server Y sind lokales Intranet dann verhält sich der Exploider genauso - Zeugs von extern ist unsicher und wird nicht oder nur mit UAC Meldung ausgeführt.

[conquestador]

Zuerst mal vielen Dank, dass ihr euch so reinhängt.
Ich hatte die letzten Tage keine Zeit, um an dem Thema weiter zu arbeiten. Ich hoffe, ich komme da morgen dazu, eure Ideen und Hinweise zu überdenken. Ich habe für morgen geplant, in einem anderen Standort, auf einer alte Büchse ein Linux zu zaubern und dann mal weiter zu forschen.
Ich melde mich wieder...