Nextcloud Berechtigungen bei SMB/CIFS auf Homes

Hallo,

Ich habe die Homeverzeichnisse für Lehrer und Schüler über das Nextcloud Plugin „External Storage“ erfolgreich eingebunden.

sudo -u www-data php occ files_external:list

| 2 | /Home_auf_Server | SMB / CIFS | Log-in credentials, save in database | host: „10.0.0.1“, share: „default-school“, root: „teachers/$user“, domain: „FZI“, show_hidden: false, check_acl: false, timeout: „“ | | | teachers |
| 3 | /Home_auf_Server | SMB / CIFS | Log-in credentials, save in database | host: „10.0.0.1“, share: „default-school“, root: „/students“, domain: „FZI“, show_hidden: false, check_acl: false, timeout: „“ | | | students |

Das funktioniert auch soweit und ich kann die Dateien im Homeverzeichnis sehen. Als Lehrer lande ich direkt im Homeverzeichnis, als Schüler navigiere ich über die Klasse ins Homeverzeichnis. Ich kann auch Dateien anlegen, allerdings nur in solchen Verzeichnissen, welche auf dem Server folgende Berechtigungen haben z.B.:

drwxrwx---+  3     3000000 users 4096 Jun 23 10:09  transfer

Wenn die Ordner folgende Berechtigungen haben klappt das anlegen von Dateien nicht z.B.:

drwxrwx---+  3 FZI\lehrer1 users 4096 Jun 23 14:18  Downloads

Der Fehler in Nextcloud lautet dann:

"Sie haben keine Berechtigung, hier Dateien hochzuladen oder zu erstellen"

Was muss ich hier noch ändern? Über Hinweise wäre ich dankbar!

Viele Grüße
Klaus

Interessanter / wichtiger sind hier die erweiterten Dateirechte, nicht die Unix Dateirechte.

Du kannst dir das zB. über getfacl, einen Windows client (rechtklick eigenschaften) oder sophomorix anzeigen lassen.

Die Berechtigungen sollten 1:1 dem entsprechen was du auch im Client siehst, alles andere wäre auch ein grobes Sicherheitsloch.

Die Nextcloud macht ja nun nichts anderes als auch dein Windows / Linux / macOS Client beim Zugriff auf den Schulserver.

Hallo Andreas,

danke für die Info!

Ich hatte dann noch im Windows einen Ordner erstellt und dort konnte ich in Nextcloud Dateien schreiben.
Und ich ich hatte mir dann auch die ACL’s angesehen - diese waren identisch. Beim Ordner Downloads konnte ich nicht schreiben, beim Ordner „Neuer Ordner“ schon.
Mit einem Test vom Nextcloud Server über „smbclient“ konnte ich mit mkdir überall ein Verzeichnis erstellen. Jetzt war ich ratlos.
Mir ist dann noch eingefallen, daß ich zwischenzeitlich mit Ordnerumleitungen via GPO getestet hatte. Das habe ich aber wieder rückgängig gemacht. Jeder Lehrer/Schüler, der sich seither am Server angemeldet hatte, hatte auch in Nextcloud diese Berechtigungs Fehler.
Da das System neu ist, habe ich jetzt kurzerhand alle Schüler- und Lehrer Homes auf dem Server gelöscht und mit „sophomorix-repair --all“ neu erstellen lassen.

Warum das aber so war kann ich nicht nachvollziehen.

Viele Grüße
Klaus

Hallo Klaus.
Ich kann leider erneut keine konkrete Lösung sondern nur einen „Meta-Hinweis“ geben:

hth,
Michael

Hallo Michael,

Meta Hinweise sind immer gut :slight_smile: Oft ist man so in seinen Denkstrukturen gefangen, daß man nichts anderes mehr sieht.

Viele Grüße
Klaus

Hallo zusammen,

Ich habe das gleiche Problem, allerdings möchte ich nicht einfach die Homeverzeichnisse löschen und neu erstellen.
Ich habe auch einen Unterschied bei den Berechtigungen mit getfactl gefunden:

Hier ein beschreibbares Verzeichnis:

# file: Dokumente/
# owner: LINUXMUSTER\134zedlerdo
# group: users
user::rwx
user:root:rwx
user:3000010:rwx
user:3000013:rwx
user:3000050:rwx
group::---
group:users:---
group:LINUXMUSTER\134admins:rwx
group:LINUXMUSTER\134global-admins:rwx
group:LINUXMUSTER\134zedlerdo:rwx
group:3000050:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000010:rwx
default:user:3000013:rwx
default:user:LINUXMUSTER\134zedlerdo:rwx
default:user:3000050:rwx
default:group::---
default:group:users:---
default:group:LINUXMUSTER\134admins:rwx
default:group:LINUXMUSTER\134global-admins:rwx
default:group:LINUXMUSTER\134zedlerdo:rwx
default:group:3000050:rwx
default:mask::rwx
default:other::---

Hier eines, bei dem es den Fehler gibt:

# file: Downloads/
# owner: LINUXMUSTER\134zedlerdo
# group: users
user::rwx
user:root:rwx
user:3000010:rwx
user:3000013:rwx
user:3000024:rwx
group::---
group:users:---
group:LINUXMUSTER\134admins:rwx
group:LINUXMUSTER\134global-admins:rwx
group:3000024:rwx
group:LINUXMUSTER\134zedlerdo:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000010:rwx
default:user:3000013:rwx
default:user:3000024:rwx
default:user:LINUXMUSTER\134zedlerdo:rwx
default:group::---
default:group:users:---
default:group:LINUXMUSTER\134admins:rwx
default:group:LINUXMUSTER\134global-admins:rwx
default:group:3000024:rwx
default:group:LINUXMUSTER\134zedlerdo:rwx
default:mask::rwx
default:other::---

Es ist bei allen problematischen Verzeichnissen die Gruppe group:3000024:rwx und bei allen funktionierenden die Gruppe group:3000050:rwx zu finden.
Was bedeuten diese IDs?

EDIT:
Bei neu erstellten Verzeichnissen tritt das Problem nicht auf.

Viele Grüße
Dorian

Hallo Dorian,

in Deinem Fall sollte ein sophomorix-repair --all aber Abhilfe schaffen.

Viele Grüße
Klaus

Die IDs werden durch sophomorix so gesetzt. Allerdings kann ich mir vorstellen, daß das nicht ganz korrekt gemacht wird, sonst könnten die IDs in Namen aufgelöst werden.

Wenn ich z.B. mal schaue:

# getfacl /srv/samba/schools/default-school/share/classes/testklasse
getfacl: Entferne führende '/' von absoluten Pfadnamen
# file: srv/samba/schools/default-school/share/classes/testklasse
# owner: 3000004
# group: users
user::rwx
user:root:rwx
user:3000004:rwx
user:3000018:rwx
user:3000021:rwx
user:3000030:rwx
group::---
group:users:---
group:LINUXMUSTER\134admins:rwx
group:LINUXMUSTER\134global-admins:rwx
group:LINUXMUSTER\134testklasse:rwx
mask::rwx
other::---
default:user::rwx
default:user:root:rwx
default:user:3000004:rwx
default:user:3000018:rwx
default:user:3000021:rwx
default:user:3000023:rwx
default:user:3000030:rwx
default:group::---
default:group:users:---
default:group:LINUXMUSTER\134admins:rwx
default:group:LINUXMUSTER\134global-admins:rwx
default:group:\134owner\040rights:rwx
default:group:LINUXMUSTER\134testklasse:rwx
default:mask::rwx
default:other::---

Hier gibt es also einen User mit der UID 3000004
default:user:3000004:rwx

Das ist aber keine UID, sondern eine GID:

# getent group |grep 3000004
BUILTIN\administrators:x:3000004:

Deshalb denke ich, daß sophomorix hier die UNIX ACL nicht richtig setzt. D.h. die GID wird als UID verwendet. Die NT ACL passen ja:

# smbcacls //server/default-school /share/classes/testklasse -U global-admin
Enter LINUXMUSTER\global-admin's password: 
REVISION:1
CONTROL:SR|DP
OWNER:BUILTIN\Administrators
GROUP:LINUXMUSTER\Domain Users
ACL:Owner Rights:ALLOWED/OI|CI|IO/CHANGE
ACL:LINUXMUSTER\testklasse:ALLOWED/0x0/RWX
ACL:LINUXMUSTER\testklasse:ALLOWED/OI|CI|IO/CHANGE
ACL:LINUXMUSTER\admins:ALLOWED/OI|CI|I/CHANGE
ACL:LINUXMUSTER\global-admins:ALLOWED/OI|CI|I/FULL
ACL:LINUXMUSTER\Administrator:ALLOWED/OI|CI|I/FULL

Vielleicht interpretiere ich das aber auch nicht richtig.

Viele Grüße
Klaus

Hallo Klaus,

bist Du denn sicher, dass es nicht auch einen User mit dieser GID gibt?

Also: getent passwd | grep 3000004

Beste Grüße

Jörg

Hallo Jörg,

ja, das habe ich verifiziert. Einen User mit der UID 3000004 gibt es nicht.
getent passwd liefert aber andere Ergebnisse des AD über winbind.

Viele Grüße
Klaus

Hallo Klaus,

Leider hat sophomorix-repair --all bei mir nicht geholfen …
Gibt es noch eine andere Möglichkeit?
Und warum steht eigentlich immer 134 vor dem Nutzernamen?

Viele Grüße
Dorian

Hallo Dorian,

Du könntest ja mal für die beiden Verzeichnisse das Ergebnis von smbcacls probieren und vergleichen.

134 ist Octal für Backslash
040 ist Octal für Leerzeichen

Der Backslash davor maskiert wohl das Octalzeichen davor als Text ausgewertet zu werden.

Also nur eine andere Anzeige des Zeichens und kein Problem.

Viele Grüße
Klaus

Hallo Klaus,

Danke für den Tipp!
Das Ergebnis ist Folgendes:
Der Dokumente Ordner (funktioniert):

REVISION:1
CONTROL:SR|DP
OWNER:LINUXMUSTER\zedlerdo
GROUP:LINUXMUSTER\Domain Users
ACL:LINUXMUSTER\zedlerdo:ALLOWED/OI|CI/FULL
ACL:LINUXMUSTER\Domain Users:ALLOWED/OI|CI/
ACL:LINUXMUSTER\Domain Users:ALLOWED/0x0/
ACL:Owner Rights:ALLOWED/0x0/READ
ACL:LINUXMUSTER\zedlerdo:ALLOWED/0x0/READ
ACL:LINUXMUSTER\global-admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\admins:ALLOWED/0x0/READ
ACL:Owner Rights:ALLOWED/0x0/READ
ACL:LINUXMUSTER\global-admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\Administrator:ALLOWED/0x0/READ
ACL:EVERYONE:ALLOWED/0x0/READ
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:CREATOR GROUP:ALLOWED/OI|CI|IO/
ACL:Owner Rights:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\global-admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\admins:ALLOWED/OI|CI|IO/FULL
ACL:Owner Rights:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\zedlerdo:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\global-admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\Administrator:ALLOWED/OI|CI|IO/FULL
ACL:EVERYONE:ALLOWED/OI|CI|IO/

Der Downloads Ordner (funktioniert nicht):

REVISION:1
CONTROL:SR|DP
OWNER:LINUXMUSTER\zedlerdo
GROUP:LINUXMUSTER\Domain Users
ACL:LINUXMUSTER\zedlerdo:ALLOWED/OI|CI/FULL
ACL:LINUXMUSTER\Domain Users:ALLOWED/OI|CI/
ACL:LINUXMUSTER\Domain Users:ALLOWED/0x0/
ACL:LINUXMUSTER\zedlerdo:ALLOWED/0x0/READ
ACL:S-1-5-21-738794539-3324739845-3936600240-1136:ALLOWED/0x0/READ
ACL:LINUXMUSTER\global-admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\admins:ALLOWED/0x0/READ
ACL:S-1-5-21-738794539-3324739845-3936600240-1136:ALLOWED/0x0/READ
ACL:LINUXMUSTER\global-admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\admins:ALLOWED/0x0/READ
ACL:LINUXMUSTER\Administrator:ALLOWED/0x0/READ
ACL:EVERYONE:ALLOWED/0x0/READ
ACL:CREATOR OWNER:ALLOWED/OI|CI|IO/FULL
ACL:CREATOR GROUP:ALLOWED/OI|CI|IO/
ACL:S-1-5-21-738794539-3324739845-3936600240-1136:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\global-admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\zedlerdo:ALLOWED/OI|CI|IO/FULL
ACL:S-1-5-21-738794539-3324739845-3936600240-1136:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\global-admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\admins:ALLOWED/OI|CI|IO/FULL
ACL:LINUXMUSTER\Administrator:ALLOWED/OI|CI|IO/FULL
ACL:EVERYONE:ALLOWED/OI|CI|IO/

Bei dem Downloads Ordner steht statt ACL:Owner Rights:ALLOWED/OI|CI|IO/FULL immer ACL:S-1-5-21-738794539-3324739845-3936600240-1136:ALLOWED/OI|CI|IO/FULL da … was hat das zu bedeuten? Ich gehe mal davon aus, dass das das Problem ist, oder?

Viele Grüße
Dorian

Hallo zusammen,

Ich hab einen Workaround gefunden:
Man installiert diese App: https://apps.nextcloud.com/apps/permissions_overwrite
Und führt dann folgende Befehle im Nextcloud Webroot aus:

sudo -u www-data php ./occ files_external:list

Dort merkt man sich die Mount ID des shares mit dem Permission Problem und macht dann folgendes:

sudo -u www-data php ./occ permissions_overwrite:set <ID> / ALL

("<ID>" durch die Mount ID ersetzten)
Damit verschwindet das Problem :slight_smile:

Viele Grüße
Dorian

Hallo Dorian,

sophomorix-repair, repariert nur diejenigen Ordner, welche auch selber durch sophomorix angelegt wurden. Also keine Unterordner. Mein Fehler.

Der Workaround, den Du gefunden hast ist bestimmt praktisch. Ohne zu wissen, wie die App genau funktioniert, sehe ich es aber dennoch kritisch, wenn man damit die Berechtigungen, so wie der Linuxmuster Server diese vorgibt, zu übergehen.

Anstatt eine App zu programmieren/installieren, welche einen Bug in Nextcloud/External Storage App/Samba/NTACL/Unix ACL etc. umgeht, wäre es doch besser die Ursache zu finden und somit die Produkte zu verbessern.

Wenn Du den Fehler also noch reproduzieren kannst wäre es prima, wenn Du die Zeit findest hier noch etwas Fehlersuche zu betreiben.

Viele Grüße
Klaus

Hallo Klaus,

Da hast du recht, langfristig wäre das auf jeden Fall besser :slight_smile:
Ich habe nur leider wenig Erfahrung mit dem ganzen Samba Kram, weshalb des Troubleshooting relativ schwierig ist.
Es könnte auch sein, dass die Ordnerrechte gar nicht falsch sind, denn mit anderen Clients kann man ja schreiben. In dem Fall wäre es ein Bug in Nextcloud und nicht in Linuxmuster.net, was durchaus sein kann, denn die angesprochene App ist ja genau für solche Fälle entwickelt worden, was darauf hindeutet, dass es ein häufiger Fehler ist.

In dem Fall müsste man sich mal den Code von Nextcloud anschauen, bzw. den teil vom external storage Plugin, der die Berechtigungen liest. Allerdings stecke ich da meine Zeit im Moment lieber in die Entwicklung des neuen LinboGUI, da kann ich glaube ich effektiver zu Linuxmuster beitragen :slight_smile:

Wenn ich aber doch noch was finden sollte, sag ich natürlich bescheid.

Viele Grüße
Dorian

Hallo Dorian,

ich denke auch, daß es eher ein Bug in Nextcloud/App ist. Und natürlich hast Du auch Recht, daß man seinen Einsatz in Opensource Projekten zeitlich einteilen muß und nicht alles machen kann. Mir ist es auch lieber Du entwickelst hier mit :slight_smile: Hab von der neuen GUI schon gelesen und bin gespannt!

Danke!

Viele Grüße
Klaus