Nun scheint aber von Windows Client was mit der Anmeldung nicht mehr zu stimmen wenn die Clients per Samba auf das Depot zugreifen müssen. Im Client Log steht:
Code: Alles auswählen
[3] [2022-08-29 11:29:28.165] [event processing on_demand{user_logged_in}] Failed to process product action requests: Failed to mount '\\192.168.1.19\opsi_depot': (5, 'WNetAddConnection2', 'Zugriff verweigert') (EventProcessing.py:797)
Traceback (most recent call last):
File "OPSI\System\Windows.py", line 844, in mount
pywintypes.error: (5, 'WNetAddConnection2', 'Zugriff verweigert')
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "opsiclientd\EventProcessing.py", line 779, in processProductActionRequests
File "opsiclientd\EventProcessing.py", line 900, in runActions
File "opsiclientd\EventProcessing.py", line 413, in mountDepotShare
File "OPSI\System\Windows.py", line 849, in mount
RuntimeError: Failed to mount '\\192.168.25.19\opsi_depot': (5, 'WNetAddConnection2', 'Zugriff verweigert')
Im Samba Log habe ich dann gesehen, dass sich wohl der PC am Samba Server zwar mit pcpatch Versucht anzumelden, aber inkl. der Windows Domäne der PCs. In der Windows Domäne ist natürlich der user "pcpatch" nicht vorhanden. Also von Hand diesen im Windows AD erfasst inkl. dem zuvor festgelegten Passwort das ich oben verwendet hatte.
Das hatte zwar den Effekt das die oben genannte Anmeldung klappte, aber der Test Client dann meckerte das er keine Daten lesen kann. Da natürlich jetzt für den OPSI Server (Der per Kerberos am AD angemeldet ist) zwei pcpatch User existieren und da natürlich von der Linux UID ein andere User greift.
Code: Alles auswählen
getent passwd | grep pcpatch
pcpatch:x:992:992::/var/lib/opsi:/bin/false
pcpatch:*:31232:30513::/home/DOMAIN/pcpatch:/bin/bash
Sonst eine manuelles Mounten von einem Linux PC aus klappt mit dem von mir gesetzen Passwort am Debot, aber halt ohne Nennung der Windows Domäne.
Habe ich hier irgendwo einen Denkfehler oder gab es eine Änderung von 4.1 auf 4.2 die ich irgendwo nur noch nicht gelesen habe und noch umsetzen muss?mount -ousername=pcpatch //192.168.1.19/opsi_depot /mnt/test/
Password for pcpatch@//192.168.1.19/opsi_depot: ************
Edit:
Während ich auf Freischaltung wartete für den Thread, habe ich nun die Lösung in einem anderen Forumbeitrag gefunden. viewtopic.php?p=56997#p56997 hat mir den Hinweis gegeben da mal in die Config zu schauen.
Nachdem ich bei "clientconfig.depot.user" von "DOMAIN\pcpatch" auf "pcpatch" und "clientconfig.windows.domain" von "WORKGROUP" auf "DOMAIN" gändert habe.
Klappte die Anmeldung wieder so wie früher und auch Aktualisierungen konnten durchgeführt werden auf dem Client. Zumindest sehe ich aktuell das er was auf dem Client installiert.
(Der Name DOMAIN ist nur n Platzhalter für die Richtige Domain)