18
Von Netzlaufwerk ins Programmverzeichnis - eine Frage der Rechte
Moin,
ich würde gerne per skript (obs nun cmd oder powershell ist sei dahingestellt) - dateien von einem Netzwerkshare nach C:\Program Files\ kopieren.
Nun ist es so, führe ich das skript als unser aus, kann ich nicht ohne erhöhte rechte ins Programmverzeichnis schreiben, führe ich das skript mit erhöhten rechten aus, sind die gemappten Netzlaufwerke des unpriviligierten users nicht mehr sichtbar.
Wie wäre sowas zu lösen?
Wäre interessant das es ein User "on Demand" selbst ausführen könnte (im zweifel hat der user adminrechte) - aktuell mache ich das "von außen" - d.h. kopiere als domain admin.
ich würde gerne per skript (obs nun cmd oder powershell ist sei dahingestellt) - dateien von einem Netzwerkshare nach C:\Program Files\ kopieren.
Nun ist es so, führe ich das skript als unser aus, kann ich nicht ohne erhöhte rechte ins Programmverzeichnis schreiben, führe ich das skript mit erhöhten rechten aus, sind die gemappten Netzlaufwerke des unpriviligierten users nicht mehr sichtbar.
Wie wäre sowas zu lösen?
Wäre interessant das es ein User "on Demand" selbst ausführen könnte (im zweifel hat der user adminrechte) - aktuell mache ich das "von außen" - d.h. kopiere als domain admin.
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 356361
Url: https://administrator.de/forum/von-netzlaufwerk-ins-programmverzeichnis-eine-frage-der-rechte-356361.html
Ausgedruckt am: 08.04.2025 um 01:04 Uhr
18 Kommentare
Neuester Kommentar
Hi.
Nun ist es so, führe ich das skript als unser aus, kann ich nicht ohne erhöhte rechte ins Programmverzeichnis schreiben
Ohne erhöhte Rechte? So so. Und wie gehst Du dabei vor? Normal geht das nicht, da läuft etwas krumm.
Hi,
wenn Du beim Erlangen der erhöten Rechte ein anderes Benutzerkonto angibts (einen Admin) dann ist dieses Verhalten logisch, weil dann der Benutzerkontext gewechselt wird, und im neuen Benutzerkontext die Netzlaufwerke des anderen Benutzers nicht da sind.
Das "Recht", worum es hier geht, ist die Mitgliedschaft in der lokalen Gruppe "Administratoren".
Also entweder, der ausführende Benutzer kommt in diese Gruppe und kann dann elevieren ohne neue Anmeldedaten, oder Du änderst einfach die Rechte des Ordners "C:\Program Files", sodass dort dieser Benutzer schreiben darf.
E.
wenn Du beim Erlangen der erhöten Rechte ein anderes Benutzerkonto angibts (einen Admin) dann ist dieses Verhalten logisch, weil dann der Benutzerkontext gewechselt wird, und im neuen Benutzerkontext die Netzlaufwerke des anderen Benutzers nicht da sind.
Das "Recht", worum es hier geht, ist die Mitgliedschaft in der lokalen Gruppe "Administratoren".
Also entweder, der ausführende Benutzer kommt in diese Gruppe und kann dann elevieren ohne neue Anmeldedaten, oder Du änderst einfach die Rechte des Ordners "C:\Program Files", sodass dort dieser Benutzer schreiben darf.
E.
Tag,
oder die einfache Variante(aber nicht die beste).
Cmd als Admin starten und:
eingeben, natürlich auch als Batch möglich auch mit Passwort.
Gruß
oder die einfache Variante(aber nicht die beste).
Cmd als Admin starten und:
net use N: \\server\freigabe /user:domäne\benutzerGruß
Was meinst du genau?
wenn ich ohne admin rechte per kommandozeile z.B. mkdir C:\program FIles\test mache, kommt da "Zugriff verweigert" - ist ja auch "by Design" so.
wenn ich ohne admin rechte per kommandozeile z.B. mkdir C:\program FIles\test mache, kommt da "Zugriff verweigert" - ist ja auch "by Design" so.
Ich schätze, @dww hat das "nicht" in Deinem Text überlesen ...
Wenn ich als User (der in der Gruppe administratoren bin), und dann die cmd "als administrator" ausführe, habe ich keinen zugriff auf die Netzlaufwerke mehr
@canlot:
yoar.. kann man machen, aber wie du selbst schreibst erscheint es mir nicht als die eleganteste lösung.
man müsste ja einen user fürs net use anlegen dessen passwort in skript plaintext steht, d.h. diesen user extra restriktiv gestalten das er nur auf das netzverzeichnis zugriff hat wo die zu kopierenden skripte / dateien liegen.
Danke für die Antwort auf jeden Fall - aber es müsste einen anderen weg geben...
yoar.. kann man machen, aber wie du selbst schreibst erscheint es mir nicht als die eleganteste lösung.
man müsste ja einen user fürs net use anlegen dessen passwort in skript plaintext steht, d.h. diesen user extra restriktiv gestalten das er nur auf das netzverzeichnis zugriff hat wo die zu kopierenden skripte / dateien liegen.
Danke für die Antwort auf jeden Fall - aber es müsste einen anderen weg geben...
UNC Pfade nutzen oder Registry-Eintrag EnableLinkedConnections auf 1 setzen, alter Hut ...
Hi,
ah, stimmt, UNC Plade wäre hier die lösung - Danke
Dieses LinkedConnections funktioniert bei Windows10 scheinbar nicht mehr
ah, stimmt, UNC Plade wäre hier die lösung - Danke
Dieses LinkedConnections funktioniert bei Windows10 scheinbar nicht mehr
UNC Pfade kannst du nur in Powershell nutzen aber nicht mit dem Commander(cmd), soweit ich weiß.
Wusstest du aber schon, denke ich.
Wusstest du aber schon, denke ich.
der "copy" befehlt von cmd kann auch UNC - aber man sollte von dem alten Krämpel ja so langsam weg :-P
Zitat von @canlot:
UNC Pfade kannst du nur in Powershell nutzen aber nicht mit dem Commander(cmd), soweit ich weiß.
Wusstest du aber schon, denke ich.
UNC Pfade kannst du nur in Powershell nutzen aber nicht mit dem Commander(cmd), soweit ich weiß.
Wusstest du aber schon, denke ich.
Jetzt nicht Dein Ernst ?
Klar kann man auch UNC innerhalb von CMD nutzen.
Und es ist kein Commander, es ist ein Command Prompt.
Zitat von @canlot:
UNC Pfade kannst du nur in Powershell nutzen aber nicht mit dem Commander(cmd), soweit ich weiß.
Der Kracher des Tages UNC Pfade kannst du nur in Powershell nutzen aber nicht mit dem Commander(cmd), soweit ich weiß.
...Wusstest du aber schon, denke ich.
Nö, dat wäre brand new min Jung.So ein Quatsch was hier mancher von sich gibt ...
Naja gut, genug auf dem mann rumgebasht (<-- wortspiel)
Aber um das hier abzuschließen, hier noch eine nette Methode bei dem sich das Powershell Skript selbst prüft ob es mit admin-rechten läuft, und falls nicht, sich selbst mit erhöhten rechten startet:
https://www.heise.de/ct/hotline/PowerShell-Skript-mit-Admin-Rechten-1045 ...
(dadurch können es die User per doppelklick ausführen, ohne nachzudenken)
Aber um das hier abzuschließen, hier noch eine nette Methode bei dem sich das Powershell Skript selbst prüft ob es mit admin-rechten läuft, und falls nicht, sich selbst mit erhöhten rechten startet:
https://www.heise.de/ct/hotline/PowerShell-Skript-mit-Admin-Rechten-1045 ...
(dadurch können es die User per doppelklick ausführen, ohne nachzudenken)
:offtopic:
Oh, wie die IT-Experten sich immer abfeiern, nur wenn jemand was falsches gesagt hat.
Da geht doch einer bei euch ab, oder?
Ein Gefühl der Überlegenheit bei der schweren Arbeit die ihr macht, so viel Stress denn man abbauen muss, da muss man doch jeden hinweisen wie scheiße er doch ist und das er keine Ahnung hätte, anstatt mal einfach freundlich hinzuweisen dass derjenige falsch lag.
Kein Wunder dass die Quote so hoch ist, dass sich Benutzer abmelden.
Ihr habt bestimmt keine Fehler gemacht, ihr seid als perfekte ITler schon geboren worden.
:offtopic:
Wenn ich mit cd in ein UNC-Pfad wechseln möchte, bekomme ich die Fehlermeldung:
CMD does not support UNC paths as current directories.
Kopieren funktioniert, habe ich gerade getestet, man lernt immer wieder dazu.
Oh, wie die IT-Experten sich immer abfeiern, nur wenn jemand was falsches gesagt hat.
Da geht doch einer bei euch ab, oder?
Ein Gefühl der Überlegenheit bei der schweren Arbeit die ihr macht, so viel Stress denn man abbauen muss, da muss man doch jeden hinweisen wie scheiße er doch ist und das er keine Ahnung hätte, anstatt mal einfach freundlich hinzuweisen dass derjenige falsch lag.
Kein Wunder dass die Quote so hoch ist, dass sich Benutzer abmelden.
Ihr habt bestimmt keine Fehler gemacht, ihr seid als perfekte ITler schon geboren worden.
:offtopic:
Wenn ich mit cd in ein UNC-Pfad wechseln möchte, bekomme ich die Fehlermeldung:
CMD does not support UNC paths as current directories.
Kopieren funktioniert, habe ich gerade getestet, man lernt immer wieder dazu.
Hier feiert sich keiner. Es geht nur darum, keine Unwahrheiten auszuschreiben.
cd will keine UNC-Pfade, das ist richtig.
Aber fast alles andere geht.
Und wenn Du dann noch mit TAB arbeitest funktioniert sogar Autovervollständigen.
Kein Grund hier abzugehen wie ein Zäpfchen.
cd will keine UNC-Pfade, das ist richtig.
Aber fast alles andere geht.
C:\>dir "S-Grosshirn\Stuff
Datenträger in Laufwerk \\S-Grosshirn\Stuff: ist Daten
Volumeseriennummer: E852-C02B
Verzeichnis von \\S-Grosshirn\Stuff
30.08.2017 13:08 <DIR> .
30.08.2017 13:08 <DIR> ..
12.02.2016 08:14 <DIR> Advanced Tokens Manager v3.5 RC 4(1)
12.02.2016 08:15 <DIR> Anleitungen
07.11.2016 13:53 <DIR> CABackup
16.12.2016 14:22 1.065.376 ChromeSetup.exe
28.08.2017 21:53 <DIR> E-Books
...sinp...
2 Datei(en), 1.065.528 Bytes
12 Verzeichnis(se), 1.443.018.498.048 Bytes freiUnd wenn Du dann noch mit TAB arbeitest funktioniert sogar Autovervollständigen.
Kein Grund hier abzugehen wie ein Zäpfchen.
Naja, wenn man sich nicht sicher ist und dann auch noch mit
Thread solved.
Wusstest du aber schon, denke ich.
um die Ecke kommt, hast du es dir selbst zuzuschreiben, dass man dir so kommt.Thread solved.
Hi,
CMD kann definitiv UNC-Pfade.
Aber: In der CMD kann CurDir nicht auf einen UNC-Pfad verweisen sondern immer nur auf ein Laufwerk. Letzteres kann auch ein Netzlaufwerk sein. Und jetzt wissen, warum es Netzlaufwerke überhaupt gibt ...
E.
Wenn ich mit cd in ein UNC-Pfad wechseln möchte, bekomme ich die Fehlermeldung:
CMD does not support UNC paths as current directories.
Kopieren funktioniert, habe ich gerade getestet, man lernt immer wieder dazu.
Das eine hat mit dem anderen nichts zu tun.CMD does not support UNC paths as current directories.
Kopieren funktioniert, habe ich gerade getestet, man lernt immer wieder dazu.
CMD kann definitiv UNC-Pfade.
Aber: In der CMD kann CurDir nicht auf einen UNC-Pfad verweisen sondern immer nur auf ein Laufwerk. Letzteres kann auch ein Netzlaufwerk sein. Und jetzt wissen, warum es Netzlaufwerke überhaupt gibt ...
E.
