Jun 05, 2023

2933

Ordnerfreigabe funktioniert auf neuem Server nicht

Hey zusammen,

Ich habe beim einrichten eines neuen Servers folgendes Problem:

Ich habe einen freigegebenen Ordner, bei dem ich die Sicherheitseinstellungen anpassen möchte, um einer Gruppe von Benutzern zugriff zu geben. Leider funktioniert das aber nicht korrekt.

Wenn ich eine alte bestehende Gruppe hinzufüge funktioniert alles einwandfrei....
Wenn ich eine neu erstellte Gruppe des AD hinzufüge, dann bekomme ich keinen Zugriff, die Gruppe ist sowie die alte Gruppen auch Universell und eine Sicherheitsgruppe.

Wenn ich die neu erstellte Gruppe nutze um den Zugriff auf einem anderen Server zu gewähren, dann funktioniert auch alles ohne Probleme. Nur für neue Gruppen auf dem neuen Server klappt es nicht.

Ich habe schon versucht, den Server neu zu starten, die Ordnerfreigabe zu entfernen und neu anzulegen usw., leider aber hat nichts davon geholfen.

Betriebssystem: Microsoft Windows Server 2022 Datacenter

Please also mark the comments that contributed to the solution of the article

Content-Key: 7428065480

Url: https://administrator.de/contentid/7428065480

Printed on: April 28, 2024 at 07:04 o'clock

21 Comments

Latest comment

Moin,

1) Was bedeutet "Funktioniert nicht korrekt"? Fehlermeldung?
2) Du hast dich, nachdem du dich in die "neue Gruppe" hinzugefügt hast, einmal neu an deiner Windows Workstations angemeldet?
3) Share- und NTFS-Rechte für das Share/Den Ordner im Dateisystem sind beide korrekt eingestellt?
4) Steht evtl. etwas dazu im Eventlog des Servers?

lg,
Slainte

Moin,

Zitat von @michi.wtr:

Ich habe einen freigegebenen Ordner, bei dem ich die Sicherheitseinstellungen anpassen möchte, um einer Gruppe von Benutzern zugriff zu geben. Leider funktioniert das aber nicht korrekt.

NTFS-Rechte? Freigaberechte? Beides?

Wenn ich eine alte bestehende Gruppe hinzufüge funktioniert alles einwandfrei....
Wenn ich eine neu erstellte Gruppe des AD hinzufüge, dann bekomme ich keinen Zugriff, die Gruppe ist sowie die alte Gruppen auch Universell und eine Sicherheitsgruppe.

Universelle Gruppen erhalten Rechte? Ok. Ist eher ungewöhnlich. Aber wenn es denn so sein soll.

Wenn ich die neu erstellte Gruppe nutze um den Zugriff auf einem anderen Server zu gewähren, dann funktioniert auch alles ohne Probleme. Nur für neue Gruppen auf dem neuen Server klappt es nicht.

Wie schon gefragt: Von welchen Rechten sprechen wir? Ich vermute mal den Klassiker: Du bearbeitest die NTFS-Rechte, aber die Gruppe hat auf der Freigabe-Ebenen keinen Zugriff.

Liebe Grüße

Erik

1) habe einfach keinen Zugriff, kann den geteilten Ordner nicht im Explorer öffnen
2) ja habe mich neu angemeldet, und auch mit "net user /domain "user name" wird alles korrekt angezeigt bzw. mit ([adsisearcher]"samaccountname=user name").FindOne().Properties.memberof
3) Habe bei den Sicherheitseinstellungen die Gruppe hinzugefügt mit lese und schreibrechte. Dann den Ordner freigegeben und in den Einstellungen bei "Jeder" "Lesen" und "Schreiben" aktiviert.
4) Was wäre das richtige Eventlog dafür? Habe mal System und Security durchsucht, da war aber nichts drin.

lg,
Micha

Zitat von @erikro:
NTFS-Rechte? Freigaberechte? Beides?

Beides

Zitat von @erikro:
Universelle Gruppen erhalten Rechte? Ok. Ist eher ungewöhnlich. Aber wenn es denn so sein soll.

Ist das ungewöhnlich ^^ ? Bei uns sind alle gruppen universell, weshalb ich meine einfach auch als universelle Gruppe erstellt habe, aber dann les ich mich da nochmal ein.

Zitat von @erikro:
Wie schon gefragt: Von welchen Rechten sprechen wir? Ich vermute mal den Klassiker: Du bearbeitest die NTFS-Rechte, aber die Gruppe hat auf der Freigabe-Ebenen keinen Zugriff.

NTFS-Rechte habe ich für die Gruppen ausgewählt, Freigabe Rechte hat einfach jeder Lesen und Schreiben.

lg,
Micha

Zitat von @michi.wtr:

1) habe einfach keinen Zugriff, kann den geteilten Ordner nicht im Explorer öffnen

Fehlermeldung? Was passiert, wenn Du in der Adresszeile des Explorers

\\servername

eingibst? Wird die Freigabe angezeigt? Lässt sich der Server anpingen?

Zitat von @erikro:

Zitat von @michi.wtr:

1) habe einfach keinen Zugriff, kann den geteilten Ordner nicht im Explorer öffnen

Fehlermeldung? Was passiert, wenn Du in der Adresszeile des Explorers

\\servername

eingibst? Wird die Freigabe angezeigt? Lässt sich der Server anpingen?

Lässt sich anpingen, und wenn ich z.B. einfach eine andere Gruppe nehme in der ich Mitglied bin für die NTFS Rechte funktioniert das auch. Wenn ich \\servername im Explorer eingebe, dann komme ich auch auf den Server und sehe die anderen geteilten Ordner. Meinen auch wenn ich ihn denn sichtbar mache, aber ich habe ihn versteckt mit Ordnername$.

Deshalb dachte ich eben es muss an der Gruppe liegen, dass ich dafür etwas falsch gemacht hätte. Die ist aber genau gleich angelegt wie die bisherigen Gruppen auch, nur die OU ist anders für den LDAP.
Wenn ich der Gruppe aber NTFS Rechte für einen Ordner auf einem anderen Server gebe, dann funktioniert das auch einwandfrei, weshalb ich nicht denke, dass der Fehler im AD liegt.

Gerade habe ich noch etwas gemerkt, wenn ich einen Ordner auf einem anderen Laufwerk freigebe C: dann gibt es auch kein Problem?? Nur auf Laufwerk D:, jedoch nur mit den neu erstellten Gruppen wie gesagt.
Die NTFS Rechte für D: sind aber dieselben wie für C:

Moin,

Ist das ungewöhnlich ^^ ? Bei uns sind alle gruppen universell, weshalb ich meine einfach auch als universelle Gruppe erstellt habe, aber dann les ich mich da nochmal ein.

Wenn du mehrere Domänen in einer Gesamtstruktur hast, Nein. Anderenfalls Ja.
Active Directory security groups. Als Zugabe noch einen Link zu AGDLP: Windows-Gruppen richtig nutzen.

Die NTFS Rechte für D: sind aber dieselben wie für C:

Die NTFS Rechte der Laufwerke spielt erst einmal eine Rolle. Viel wichtiger sind die Rechte des freigegebenen Verzeichnisses. In der Regel trägt man in die Permission für das Share "Authenticate User" => "Full Control" ein. Die granulare Permissions werden dann über NTFS geregelt. Du kannst dort die Gruppe eintragen und ebenfalls zum Testen "Full Control" vergeben. Wenn dein Testnutzer Mitglied der Gruppe ist und in seinem Token diese Mitgliedschaft auch aktiv ist, sollte der Zugriff nun klappen.

Gruß,
Dani

Zitat von @Dani:
In der Regel trägt man in die Permission für das Share "Authenticate User" => "Full Control" ein. Die granulare Permissions werden dann über NTFS geregelt. Du kannst dort die Gruppe eintragen und ebenfalls zum Testen "Full Control" vergeben. Wenn dein Testnutzer Mitglied der Gruppe ist und in seinem Token diese Mitgliedschaft auch aktiv ist, sollte der Zugriff nun klappen.

Das hat gestern leider auch nicht funktioniert, hatte mir Vollzugriff im NTFS und auch für die Freigabe gegeben. Das Problem trat aber nur bei den neu erstellten Gruppen auf, die ich für ein Projekt benötige.

Kurz vor Feierabend habe ich gestern nochmal versucht auf den Ordner zuzugreifen, kam aber nicht drauf... Heute morgen komme ich zur Arbeit und habe plötzlich wieder Zugriff. Keine Ahnung warum, gestern hat es gute 8 Stunden nicht funktioniert und auf einmal geht es. Evtl. muss ich mich mal noch ein bisschen in Ordnerfreigaben einlesen, nicht dass das Problem irgendwo auf dem DC liegt...

Vielen Dank,
Micha

Moin,

kann das sein, dass Du Dich nach dem Hinzufügen zur Gruppe nicht neu angemeldet hast? Das wäre dann der Klassiker.

Liebe Grüße

Erik

Zitat von @erikro:

Moin,

kann das sein, dass Du Dich nach dem Hinzufügen zur Gruppe nicht neu angemeldet hast? Das wäre dann der Klassiker.

Liebe Grüße

Erik

Das habe ich heute auch schon noch paar mal im Internet nachgelesen, dass bei der Anmeldung mit dem DC ein Usertoken für die Sitzung ausgestellt wird, in dem die SIDs für Gruppen etc. stehen. Aus diesem Token wird das dann alles ausgelesen. Ergo, alte Gruppen, in denen ich schon lange Mitglied war, waren in diesem Token enthalten, weshalb ich mit diesen auch Zugriff auf den Ordner hatte

Aber ich suche gerade noch im Netz eine Möglichkeit das Usertoken neu zu erstellen, ist schon etwas lästig, wenn man sich jedes mal neu anmelden muss zum testen...

beste Grüße,

Micha

Moin,

kinit und klist sind da Deine Freunde.

Liebe Grüße

Erik

Moin,

Ergo, alte Gruppen, in denen ich schon lange Mitglied war, waren in diesem Token enthalten, weshalb ich mit diesen auch Zugriff auf den Ordner hatte face-smile

nur gut, dass wir das Thema nicht vorher schon mehrfach erwähnt haben. ;)

Aber ich suche gerade noch im Netz eine Möglichkeit das Usertoken neu zu erstellen, ist schon etwas lästig, wenn man sich jedes mal neu anmelden muss zum testen...

wer nicht mit klist/kinit umgehen kann, meldet sich einfach an dem betroffenen Rechner ab und wieder an.

Gruß,
Dani

Zitat von @Dani:
wer nicht mit klist/kinit umgehen kann, meldet sich einfach an dem betroffenen Rechner ab und wieder an.

Ich weiß nicht wieso, aber das funktioniert bei mir tatsächlich nicht...
Mit klist purge wird mir nur folgendes angezeigt:

kinit kannte ich noch nicht:

Was kann ich mit dieser Datei unter dem angegebenen Pfad nun anfangen?

Gruß,
Micha

Moin,

Zitat von @michi.wtr:

Zitat von @Dani:
wer nicht mit klist/kinit umgehen kann, meldet sich einfach an dem betroffenen Rechner ab und wieder an.

Ich weiß nicht wieso, aber das funktioniert bei mir tatsächlich nicht...

Doch, es funktioniert. "Alle Tickets wurden gelöscht" ist genau das, was Du willst. Dann muss beim nächsten Zugriff ein neues Ticket angefordert werden, dass dann die neuen Gruppenmitgliedschaften enthält.

hth

Erik

Zitat von @erikro:
Doch, es funktioniert. "Alle Tickets wurden gelöscht" ist genau das, was Du willst. Dann muss beim nächsten Zugriff ein neues Ticket angefordert werden, dass dann die neuen Gruppenmitgliedschaften enthält.

Wie genau bekomme ich dann dieses Ticket? Denn wenn ich klist/kinit ausführe habe ich danach noch immer keinen Zugriff auf die Ordner. Nach Neuanmeldung jedoch schon. Muss ich die Datei die ich durch kinit bekomme noch irgendwo einfügen?

Moin,

Denn wenn ich klist/kinit ausführe habe ich danach noch immer keinen Zugriff auf die Ordner.

führst du die Befehle in Kontext des Benutzers durch? Ich bin grade etwas stutzig, weil in deinem Screenshot C:\Windows\system32 zu lesen ist.

Gruß,
Dani

Moin,

ich habe das gerade mit meinem User ausprobiert. Testgruppe angelegt, mich eingefügt, Befehl

klist purge

unter dem User ausgeführt und mit

net user /domain meinusername

geprüft. Gruppe wird angezeigt. Wie der Kollege @Dani schon sagte: Du musst den Befehl unter dem User, der Zugriff haben soll, ausführen.

Liebe Grüße

Erik

Zitat von @Dani:
führst du die Befehle in Kontext des Benutzers durch? Ich bin grade etwas stutzig, weil in deinem Screenshot C:\Windows\system32 zu lesen ist.

Ja, ich muss nach kinit auch meine persönlichen Credentials eingeben. Nur ist klist bei uns wohl noch etwas anderes:

Um das richtige Tool zu benutzen hab ich einfach den Pfad zu C:\windows\System32 gesetzt, da ich dort die exe für klist gefunden habe. (Hoffe nicht dass das verkehrt ist, aber ich meine die cmd.exe liegt ja auch dort drin)

Zitat von @erikro:
unter dem User ausgeführt und mit

net user /domain meinusername

geprüft. Gruppe wird angezeigt. Wie der Kollege @Dani schon sagte: Du musst den Befehl unter dem User, der Zugriff haben soll, ausführen.

Das ist mir natürlich klar, habe die cmd auch unter dem Benutzer gestartet, nur den Pfad geändert um auf klist.exe zugreifen zu können, keine Ahnung warum das bei uns so verkehrt ist ^^

net user /domain meinusername

gibt mir auch so schon immer die Gruppenmitgliedschaft mit, auch ohne Neustart, denke das wird auch ne Abfrage an den DC sein? Nur mein Token selbst aktualisiert sich eben nicht, weshalb ich zwar Mitglied in der Gruppe bin (und durch net user auch weiß) jedoch erhalte ich Zugriff erst nach Neustart, auch nach klist und kinit.

Unter System32 sieht die Hilfe dann auch so aus:

PS: Das andere klist kommt wohl aus irgend einem installierten JDK Paket oder sowas (kenne mich da leider gar nicht aus, hat ein Kollege vor einigen Monaten an alle Rechner verteilt)

Da der Pfad noch vor System32 kommt wird diese natürlich auch ausgeführt, deshalb musste ich in den System32 Ordner navigieren...

Moin,
kein Problem. Ich dachte nur, ich frag sicherheitshalber nochmals nach.

1) klist purge
2) klist tickets => Sollte nichts mehr aufgelistet werden.
3) cmd.exe als runas starten. Anmelden als aktiver Nutzer
4) whoami /groups => Gruppenmitgliedschaft müsste nun da sein.
5) Zugriff auf Verzeichnis testen.

Gruß,
Dani

Zitat von @Dani:
1) klist purge
2) klist tickets => Sollte nichts mehr aufgelistet werden.

Aktuelle Anmelde-ID ist 0:0xblablabla

Zwischengespeicherte Tickets: (0)

Das wird bei mir angezeigt, denke das ist schonmal richtig.

3) cmd.exe als runas starten. Anmelden als aktiver Nutzer

hier war mein Fehler, habe diese Anmeldung nicht durchgeführt an der cmd, dachte mit klist purge sei alles getan ^^

4) whoami /groups => Gruppenmitgliedschaft müsste nun da sein.

Jawoll, klappt einwandfrei <3
Vielen lieben Dank.

Gruß,
Micha

Nachtrag:

Hat leider doch nicht funktioniert

Wenn ich

whoami /groups

in der neu gestarteten cmd starte, dann werden mir dort natürlich die richtigen Gruppen angezeigt, wenn ich aber lokal als angemeldeter Benutzer auf dem PC normal die cmd ausführe, dann werden noch alte Gruppen vor dem klist purge angezeigt...

German solved Question Windows Server Microsoft

Hotly discussed

Developer diary: Release 6.1admtech

End of availability for classic Teams clientDani