Falsche Owner beim Erstellen von Shares

UCS - Univention Corporate Server
#1

Hallo zusammen,

bei mir ist beim Erstellen eines neuen Share-Folders über das UCS-Frontende folgendes Problem aufgetaucht: Zunächst wird scheinbar unter /etc/samba/shares.conf.d kein neuer Eintrag für den erstellten Share angelegt. Sämtliche Einstellungen habe ich von einem bereits existierenden (und funktionierendem) Share übernommen - die Freigabe funktioniert also Grundsätzlich.

Nachdem ich die entsprechenden Eintragungen bei /etc/samba/shares.conf.d und der shares.conf manuell hinzugefügt habe, taucht der Share-Ordner zwar in der Windows-Netzwerkumgebung auf, ist dann auch zugänglich.

Wenn ich mir das Verzeichis die Ausgabe von /var/flexshare allerdings mit ls -la ausgeben lasse (siehe unten, Namen geändert) fällt auf, dass der neuangelegte Share (obwohl im UCS Webfrontent mit den gleichen Ownern versehen wurde wie der bereits existierende Share) jetzt root und nogroup als Owner hat.

drwxrwx---   3 flexshare alterShareGroup        4096 Aug 26 14:18 alterShare
drwxr-xr-x   2 root      nogroup                4096 Okt 11 12:38 neuerShare

Zudem unterscheiden sich auch die gesetzten Rechte (hab ich im Webfrontent ebenfalls gleich eingestellt). Wo könnte hier das Problem bzw. mein Fehler liegen?

Schonmal vielen Dank für die Hilft!

Viele Grüße
Florian

#2

Moin,

das Anlegen der Dateien in /etc/samba/shares.conf.d sowie der Share-Verzeichnisse geschieht durch ein Listener-Modul im Univention Directory Listener. Sollte dieser nicht laufen oder nicht richtig funktionieren, kommt es zu Probleme.

Führ am Besten mal den Systemcheck über die UMC aus (oder über den Kommandozeilenbefehl univention-run-diagnostic-checks -t all). Dabei wird auch die Funktionalität des Notifier-Listener-Mechanismus untersucht.

#3

Moin,

der Systemcheck liefert - in meinen Augen - erstmal keine Fehler bezüglich des Notifers. Auch das zugehörige Logfile liefert nichts aufschlussreiches.

ran 00_check_server_password successfully
ran 01_ssh_connection successfully
ran 02_certificate_check successfully
ran 03_check_notifier_replication successfully
ran 04_saml_certificate_check successfully
ran 10_gateway successfully
ran 11_nameserver successfully
ran 12_proxy successfully
ran 20_check_nameservers successfully
ran 21_check_join_status successfully
ran 22_kdc_service successfully
ran 23_check_update_sites successfully
ran 30_disk_usage successfully
ran 31_file_permissions successfully
ran 32_security_limits successfully
ran 40_samba_tool_dbcheck successfully
ran 41_samba_tool_showrepl successfully
ran 43_connectors4_rejects successfully
ran 44_well_known_sid_check successfully
ran 45_heimdal_on_samba4_dc successfully
ran 46_kerberos_ddns_update successfully
ran 52_mail_acl_sync successfully
ran 53_package_status successfully
ran 54_sources_list_check successfully
ran 55_user_migration successfully
ran 56_univention_types successfully


############################
## Check failed: 50_check_ucr_templates - Überprüfe veränderte UCR Vorlagen
Es wurden Fehler durch `univention-check-templates` gefunden. Die folgenden UCR Vorlagen wurden lokal verändert. Aktualisierte Versionen werden DATEINAME.dpkg-* genannt. Die Dateien sollten auf Unterschiede geprüft werden.

 /etc/univention/templates/files/etc/logrotate.d/rsyslog
/etc/univention/templates/files/etc/rsyslog.conf
/etc/univention/templates/files/etc/samba/base.conf

########### End #############

############################
## Check failed: 51_hostname_check - Überprüfe Rechnernamen auf RFC Konformität
Die folgenden nicht konformen Rechnernamen wurden gefunden: (ausgeblendet).
Dies kann zu DNS Problemen führen.
Siehe {rfc1123} für die Syntax von Rechnernamen.
########### End #############
#4

Oh, da fällt mir auf:

Es gibt im Listener eine Whitelist, in welchen Pfaden überhaupt nur Shares angelegt werden dürfen (siehe ucr search --brief listener/shares). Seit einem der letzten UCS-Errata-Updates funktioniert dieser Mechanismus nun auch tatsächlich, was bedeutet, dass Pfade unterhalb von /var standardmäßig eben nicht mehr erlaubt sind, da in keiner Whitelist eingetragen.

Du kannst einen Whitelist-Eintrag ergänzen (ungetestet: ucr set listener/shares/whitelist/my-flexshare=/var/flexshare oder für ganz /var mit ucr set 'listener/shares/whitelist/var=/var/*' ; anschließend die Freigabe in der UMC einmal kurz verändern, damit der Listener wieder getriggert wird) oder die Freigabe in einen bereits gewhitelisteten Pfad wie z.B. /srv verlegen.

Edit: nach dem Setzen der Variablen sollte der Directory Listener getriggert werden, damit er seine Shares wieder verarbeitet:

univention-directory-listener-ctrl resync samba-shares
Shares create on DC don´t not configure shares on member server
Shares create on DC don´t not configure shares on member server
#5

I am not sure, if I understand that correctly. Please correct me where I am wrong:
1- some share locations are now (since whenever) blacklisted
2 - I mount all different hard disks (5) on /home-alpha, /home-beta ,/ home-cesar … They must be “whitelisted”?
3 - My command line to whitelist would be: ** ucr set ‘listener/shares/whitelist/var=/home-*’ **?
Please correct me, where I am wrong

thx

#6
  1. There has always been a mechanism that only whitelisted locations were supposed to be accepted for shares. However, that mechanism has been buggy for years, and only a recent updated fixed that bug — meaning the blacklisting/whitelisting only started to be effective a couple of errata updates ago.
  2. yes
  3. not exactly, but close; you can chose the key name’s part after listener/shares/whitelist/ yourself, and I suggest you make that name refer to the value somehow, e.g. listener/shares/whitelist/home instead of …/var. var was for the other user in the other thread who wanted to create a share in /var.

Remember to resync the directory listener Samba shares after setting the variable.

#7

deleted, wrong topic

#8

You’re posting in the wrong topic.

Mastodon