Update auf UCS 3.1 - SAMBA Probleme mit "Erzwungene Gruppe"

UCS - Univention Corporate Server
#1

Hallo,

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

Erzwungene gruppe
#2

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.

#3

Wir haben das Problem ebenfalls nach dem Update auf 3.1 festgestellt.
Bug 29553 klingt zumindest ähnlich.

#4

[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?

emg

#5

Das Update erfolgte von 3.0 auf 3.1!

#6

Hallo,

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

#7

[quote=“Meybohm”]Hallo,

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.

folgende Infos:

>getfacl RichtigeRechte
# file: RichtigeRechte
# owner: root
# group: itm-shares-folderusers
user::rwx
group::rwx
other::---
default:user::rwx
default:group::r-x
default:other::r-x

wird durch Ändern mit Windows Explorer zu:

>getfacl ZerstörteRechte
# file: ZerstörteRechte
# owner: root
# group: itm-shares-folderusers
user::-wx
user:root:rwx			#effective:-wx
user:esc:r-x			#effective:--x
group::r-x			#effective:--x
group:itm-shares-confidential:r-x#effective:--x
mask::-wx
other::---
default:user::rwx
default:user:root:rwx
default:user:esc:rwx
default:group::---
default:group:itm-shares-confidential:rwx
default:mask::rwx
default:other::---

Das tolle ist, das ich jetzt gar nicht mehr darauf zugreifen kann und einen Weg finden muss umd die Rechte per Linux Konsole Rekursiv zu setzen.

#8

Hallo Herr Meybohm,

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 :wink:
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
Mastodon