Startnet.cmd Zugriff verweigert

[henrik2810]

Guten Tag,

ich arbeite mich momentan in OPSI ein und versuche gerade einen Client mit einem Windows 7 64-bit zu installieren. Ich bin nach der Getting Started Anleitung vorgegangen und habe ein Windows PE erstellt und die Installationsdateien von einer Windows 7 DVD auf meinen Opsi Server transferriert. Ich nutze die VM Appliance und habe alles nach der Anleitung durchgeführt.
Ich habe zusätzlich die Boot CD heruntergeladen und gebrannt. Diese starte ich in dem Client und kann auch alleine geforderten Einstellungen eingeben. Es wird nun die Windows Installation gestartet.
Nun zu meinem Problem:
Es öffnet sich ein Konsolenfenster in dem die startnet.cmd aufgerufen wird. Daraufhin bekomme ich die Meldung:

X:\windows\system32>c:opsi\startnet.cmd
Initializing .... please wait.....

mountresult: 0 : Der Vorgang wurde erfolgreich beendet
Zugriff verweigert.

Hieraus wird dann eine Endlosschleife...
Kann mir hier jemand helfen?

Vielen Dank

[n.wenselowski]

Hallo henrik,

bitte auf dem OPSI-Server als root folgendes ausführen und dann noch mal probieren:

Code: Alles auswählen

opsi-setup --set-rights

Gruß

NW

[Arris]

Wir hatten hier exact den selben Fehler und ich habe mir nen Wolf gesucht...

Der Mountbefehl funktioniert, allerdings wird die setup.exe in /<opsidepot>/<produkt>/installfiles nicht ausgeführt da dateirechte 660 ohne execute
wenn man ein chmod 770 über die files macht gehts aber opsi-set-rights haut das netterweise wieder auf 660...

hoffe es hilft sonst noch jemandem,
Grüße

Gerd

[n.wenselowski]

Hallo Arris,

was für ein Server-OS wird in welcher Version verwendet?
Welche Samba-Version ist dabei?


Gruß

Niko

[Arris]

Hallo Niko,
bin gerade erst auf die Antwort aufmerksam geworden.

Opsiversion:

Code: Alles auswählen

ii  digitec-opsi-listener                              1.1-1                                        Add, remove and update windows clients in OPSI
ii  opsi-atftpd                                        0.7.dfsg-2.1                                 advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii  opsi-configed                                      4.0.4.1.2-4                                  OPSI config editor
ii  opsi-linux-bootimage                               20140118-1                                   opsi linux bootimage
ii  opsi-utils                                         4.0.4.1-2                                    opsi utils
ii  opsi4ucs                                           4.0.4.6-1                                    opsi software deployment for ucs
ii  opsiconfd                                          4.0.4.3-1                                    opsi configuration service
ii  opsipxeconfd                                       4.0.4.1-2                                    opsi pxe configuration daemon
ii  python-opsi                                        4.0.4.5-2                                    opsi python library

Das ganze läuft auf UCS 3.2-1 errata78

merci
Gerd

[ueluekmen]

Hallo Arris,

welche Serverrolle ist dein opsi-Server? Falls es ein Slave ist, hast du:

univention-run-join-scripts

ausgeführt und ist das opsi-Join-Skript durchgelaufen?

[Arris]

Hallo,
nö, ist der Master.
Join-scripte sind alle durchgelaufen.

Es funktionierte auch alles bestens, war dort allerdings noch auf experimental. Hab aus stable opsi neu installiert.
Das Rechteproblem ist gerade nicht das größte, sondern dieses:
viewtopic.php?f=6&t=6010&p=26873#p26873

Könnte es damit zu tun haben, dass ich das depot nicht neu aufgebaut habe, sondern z.B. installfiles und winpe durch kopieren gefüllt habe.

Grüße
Gerd

[ueluekmen]

Hi,

ok, probier mal:

Code: Alles auswählen

opsi-setup --init-current-config

Dieser sollte auf einem UCS die Option richtig anlegen.

Ich habe jetzt nicht jeden Post hier gelesen aber ich versuche das mal kurz zu erklären:

Wir haben bis jetzt immer nach Prinzip

Code: Alles auswählen

HOSTNAME-VOM-OPSI\pcpatch

den Share gemounted. Das hat auch immer geklappt. Auch auf Systemen mit Samba4. Vor kurzem kam ein neues Errate-Update (für Samba4), welches dieses Verhalten komplett geändert hat.

Das opsi-setup aus den neuen 4.0.4 Paketen erkennt diesen Umstand automatisch und stellt diese Config richtig ein. Da steht dann sowas wie:

LOGINDOMAIN\pcpatch. Dann klappt der mount. Zumindest hat dieser Fix die Probleme bei unseren Kunden, die UCS einsetzen gefixed.

[Arris]

Hi,
das war es leider nicht, unveränderter Zustand.
Die Rechte auf der setup.exe sind nach --set-rights noch immer auf 660.

Das Problem der Useranmeldung am Share von winpe habe ich umgangen:
viewtopic.php?f=6&t=6010

Grüße
Gerd