Nach dem Update auf UCS 3.1 kann nicht mehr auf Freigaben zugegriffen werden, die eine “Erzwungene Gruppe” haben.
Die Gruppe gibt es definitiv und es ist die selbe, die Inhaber der Freigabe ist.
Andere dürfen auf diese Freigabe garnicht zugreifen.
Vor dem Update hat alles super geklappt - Verzeichnisse und Dateien wurden immer unter der erzwungenen Gruppe angelegt.
Nach dem Update kann man auf die Freigaben nicht mehr zugreifen.
Windows meldet, das man nicht zugreifen kann, da der Gruppenname nicht bekannt ist, Linux hingegen meldet einen I/O Error.
Ich habe Momentan als Workaround die erzwungene Gruppe entfernt, was aber zu anderen Problemen führen kann.
Vielen Dank für Ihre Hilfe,
Matthias Hammerschmidt
Von welcher Version wurde das Update durchgeführt? Ich hatte das Problem schon bei Version 3.0 (frisch Installiert, Samba 4 DC plus Samba 3 File Server). Unter 2.4 hatte ich mit dieser Konfiguration keine Probleme.
[quote=“ahrnke”]Wir haben das Problem ebenfalls nach dem Update auf 3.1 festgestellt.
Bug 29553 klingt zumindest ähnlich.[/quote]
Hallo,
bei “valid users” konnte/musste(?) man früher statt der SID auch “@DOMAIN+gruppename” angeben wenn ich micht recht entsinne. Habt ihr das (und die SID) mal bei “force group” versucht?
ich konnte ein Problem mit “force group”-Shares unter 3.1 nachstellen wenn diese auf einem Samba 4 Server angelegt sind (Details unter [bug]29983[/bug]).
Shares welche auf Samba 3 Memberservern konfiguriert sind funktionieren in meinen Tests weiterhin wie erwartet.
Um die Einzelfälle prüfen zu können wären die konkreten Definitionen der Shares (udm shares/share list -filter cn=), die Berechtigungen im Dateisystem sowie die Fehlermeldung eines Verbindungsversuchs via smbclient hilfreich.
Als Workaround könnten Sie das SGID-Bit für das Share-Verzeichnis setzen:chmod g+s /path/to/share
Mit freundlichen Grüßen
Janis Meybohm
ich konnte ein Problem mit “force group”-Shares unter 3.1 nachstellen wenn diese auf einem Samba 4 Server angelegt sind (Details unter [bug]29983[/bug]).
Shares welche auf Samba 3 Memberservern konfiguriert sind funktionieren in meinen Tests weiterhin wie erwartet.
Um die Einzelfälle prüfen zu können wären die konkreten Definitionen der Shares (udm shares/share list -filter cn=), die Berechtigungen im Dateisystem sowie die Fehlermeldung eines Verbindungsversuchs via smbclient hilfreich.
Als Workaround könnten Sie das SGID-Bit für das Share-Verzeichnis setzen:chmod g+s /path/to/share
Mit freundlichen Grüßen
Janis Meybohm[/quote]
Hallo,
Das liefern der angeforderten Informationen dauert wohl noch etwas, zumal meine Probleme gerade größer werden.
Das setzen das SGID Bit hilft leider nicht. Zusätzlich scheint das setzen der Berechtigungen mit Windows-Tools komplett in die Hose zu gehen.
Ich habe mit dem Explorer über SIcherheit->Erweitert die Rechte für den Benutzer und die Gruppe auf Vollzugriff gesetzt, was darin resultiert das die Rechte nun inkonsistent sind.
Ihr Workaround war ein guter Hinweis. Allerdings zeigt sich der Nutzen bei bestehenden Strukturen natürlich nicht in Unterverzeichnissen, wenn diese schon “vergurkt” sind - sprich die falsche Gruppe haben
Das nichts mehr funktionierte, hat ja auch nichts mit Ihrem Workaround zutun, sondern mit den Rechten die der Windows Explorer erzeugt hat.
Wahrscheinlich ist unsere Kombination aus Samba4 Konfiguration mit erzwungenen Rechten und den bestehenden Dateisystem Rechten daran Schuld gewesen.
Im Detail kann ich es leider nicht mehr rekonstruieren, allerdings scheint es mir so zu sein, das Erzwungene Bits nicht wie erwartet gesetzt wurden.
Aus den von mir übermittelten Informationen mit “getfacl ZerstörteRechte” aus dem vorhergehenden Post kann man sehen das das Quatsch erzeugt wurde.
Vielleicht ist SAMBA4 auch durcheinander gekommen, da der Eigentümer nachträglich über Linux Konsole auf root gesetzt wurde (chown) mit Windows Explorer aber auf esc!?!?
Mein Fokus steht darauf wieder arbeiten zu können, aus diesem Grund ein Skript, womit wir unsere Strukturen wieder in den Griff bekommen haben.
Folgende Informationen vorweg:
[ul]
Jede Freigabe gehört genau einer Gruppe, Eigentümer der Freigabe ist root
diese Gruppe hat die Rechte: rwx
neue Elemente sollen den User als Eigentümer und die Freigaben Gruppe als Eigentümer Gruppe haben
[/ul]
Folgendes Skript:
#!/bin/bash
#
#
# Check Share Parameter
if [ -z "$1" ]
then
echo "$0: Fehlende Angabe des Share Namens"
exit 1
fi
#
# Freigabe ist 1 Parameter
SHARE=$1
# share Gruppe ist lowercase
SHARE_GROUP=shares_$(echo ${SHARE} | tr [A-Z] [a-z])
# Basis für alle Freigaben
SHARE_ROOT=/mnt/local-shares/
#
# Wechsel des Verzeichnisses
cd ${SHARE_ROOT}
#
# Rekursives setzen der Gruppe, der dieses Verzeichnis gehört
# und die UNIX Rechte setzen
chgrp -R ${SHARE_GROUP} ${SHARE}
chmod -R 770 ${SHARE}
#
# Rekursiv Stickybit setzen, damit die Gruppe für neue angelegte Elemente übernommen wird
find ${SHARE} -type d -print0 | xargs -0 -I chmod g+s "{}"
#
# Die Attribute löschen -> Sonderlocken werden damit zerstört
setfacl -R -b ${SHARE}
#
# vernünftigen Standard für Share Hauptverzeichnis setzen
setfacl -m d:u::rwx,d:g::rwx,o::-,d:m::rwx ${SHARE}
# Standard der Hauptverzeichnisse rekursiv setzen
getfacl ${SHARE} | setfacl -R -M- ${SHARE}
exit 0
