bei mir läuft die NC 20.0.5 als docker-Image. Samba habe ich dazu installiert. Hier mein Dockerfile:
FROM nextcloud:latest
RUN apt-get update && apt-get install -y procps smbclient && rm -rf /var/lib/apt/lists/*
Wenn sich ein Benutzer anmeldet werden sein Home-Verzeichnis und sein Tauschverzeichnis als samba-Share dem Benutzer zur Verfügung gestellt. Für das Tauschverzeichnis habe ich unter Einstellungen -> Externer Speicher folgendes eingestellt:
Das Problem tritt dann auf, wenn ein Benutzer sich beispielsweise in eine neue Klasse einschreibt oder sich auch einer Klasse austrägt. Dann ändern sich seine Gruppenzugehörigkieten und er hat zu manchen Verzeichnissen laut ACL keinen zugriff mehr und zu manchen Verzeichnissen hat er zusätzlichen Zugriff.
Leider ist das in der Nextcloud (Weboberfläche oder Nextcloudapp) nicht zu sehen:
Hat sich ein Benutzer aus der Klasse 8a ausgetragen, so sieht er das Tauschverzeichnis der 8a immer noch. Betritt er es, so sieht er dort keine Dateien. Und beim Verlassen erscheint diese Fehlermeldung:
Schreibt sich ein Benutzer in die Klasse 5a ein, so sieht er das entsprechende Tauschverzeichnis nicht.
Es scheint so, als ob einmal beim Einrichten der Samba-Shares die Verzeichnisse, zu denen ein Benutzer Zugriff hat gespeichert werden. Ändern sich später die Gruppenzugehörigkeiten, so wird das in der NC nicht übernommen.
Samba Shares sind auch nicht optimal. Ich war auch der NC-Konferenz vor einem Jahr und die Entwickler konnten mir die Probleme damit bestätigen. Als Tipp hatten sie mir empfohlen andersherum zu arbeiten. Also statt Samba-Sahres in NC einzubinden, NextCloud auf den Vlients einzubinden. Dafür den NC-Client installieren und auf den Clients verfügbar machen. Ich weiß, ist nicht immer optimal, ich hab dann auch drauf verzichtet, aber wenn es eine Option ist, warum nicht so.
Meine Kollegen wollen halt die Möglichkeit, von Zuhause aus auf ihre Dateien zuzugreifen…
Aber ich glaube, ich habe eine Lösung gefunden
Statt mit smbclient arbeite ich mit php-smbclient. Dann läuft alles, so, wie es sollt
Hallo zusammen,
so leicht war’s leider doch nicht. Eigenartiger weise hat die „Lösung“ mit php-smbclient am Anfang funktioniert.
Aber ich kann das Problem etwas besser eingrenzen:
Probleme entstehen nur, wenn die Gruppenzugehörigkeit geändert wird. Wenn ein Schüler beispielsweise in die Gruppe p_infoag aufgenommen wird, sieht er das Tauschverzeichnis nicht.
Und wenn ein Schüler nicht mehr in der Gruppe p_astronomie ist, sieht er zwar das entsprechende Tauschverzeichnis, aber es ist leer.
Was gut funktioniert ist, wenn jemand von einem Schulrechner etwas ins Klassentauschverzeichnis stellt, dann ist das auch in der NextCloud zu sehen und zwar sobald das Klassentauschverzeichnins betreten wird
Gruß,
Mathias
Hast du es mit einem neustart des smbclient / des php-servers (falls du php-fpm verwendest) / von apache / des Nextcloud-Server probiert, sobald du die Gruppenzugrhörigkeit änderst?
Bei Client hat man ja auch cache-effekte, vllt. auch hier?
ich habe tatsächlich die Nextcloud gestoppt, die Images gelöscht und mit docker-compose up -d --build die Images neu erstellt und gestartet.
Anfänglich hat alles wunderbar funktioniert. Nur dann, ein zwei Stunden später, hat die NC nicht mehr auf eine Änderung der Gruppenzugehörigkeit nicht mehr reagiert.
Ich verwende nextcloud:latest würdest du mir zu php-fpm raten?
Ich meinte: nach jeder Änderung die Container neu starten, nicht einmal neu starten und dann reagieren die auf jede Zugehörigkeitsänderung.
Wenn du meinst, dass du die Gruppenzugehörigkeit geändert hast, dann (mit build) neu gestartet hast und diese Änderung zuerst funktioniert und dann später einfach nicht mehr funktioniert hat (obwohl du in der zwischenzeit nichts geändert hast), dann weiß ich auch nicht warum NC das mcht.
Funktioniert heißt, dass wenn ich einen User aus der Gruppe p_infoag rausnehme, dass dann das entsprechende Tauschverzeichnis für diesen User nicht mehr sichtbar ist.
Bei jeder Änderung der Gruppenzugehörigkeit die NC mit --build neu zu starten kann keine Lösung sein. Da ich ja nicht der einzige bin, der AG- oder Klassen-Zugeförigkeiten ändert, müsste ich ja ständig die NC neu bauen.
Kannst du mir etwas zu ´fpm´ sagen? Das habe ich noch nicht versuch…
Gruß,
Mathias
Nochmal: mit neustarten meinte ich sicher nicht „build“, sondern ich meinte nur „docker-compose restart“ oder ohne docker hätte vllt. auch „systemctl restart samba“ gereicht.
php-fpm ist die alternative zu apache+modphp oder wie das heißt. Dann laufen alle PHP-Prozesse auf eigenen Kern(en) und man kann das besser skalieren, wenn es heiß hergeht. (hab ich zumindest das gefühl, villeicht geht das mit modphp auch…)
Mir ging es bloß darum, dass es dann einfach wäre, „php“ neuzustarten… falls das irgendein caching betreibt…
Aber in deinem Fall reicht voll und ganz: „docker-compose restart“…
bei PHP als fastCGI-Prozess mit FPM läuft PHP als eigener Dienst,
während beim Apache-Image PHP bei jeder Anfrage vom Webserver aufgerufen
wird.
FPM ist der modernere Ansatz und deutlich perfomanter. Mit Docker ist
aber eventuell mehr Konfiguration nötig, vor allem bei gemischten
Inhalten (html + php).
Hallo Klaus,
vielen Dank schon mal für’s Mitdenken.
Das ist bei mir schon eingestellt.
Das hilft tatsächlich, allerdings dauert so ein Scanvorgang auf meinem Server ca 2 Stunden.
Wenn ich das als Cron-Job nachts um 03:00 starte, dauert halt die Übername von Gruppenänderungen bis zum nächsten morgen.
Wäre also ein workaround.
Vielen Dank für den Tip.
Gruß,
Mathias
Hallo Jörg,
ich habe jetzt mal eine Netzcloud mit nextcloud:stable-fpm aufgesetzt. Ob das jetzt performater ist, kann ich noch nicht sagen. Was ich aber gesehen habe, ist dass es das Problem nicht löst.
Auf den Geschwindigkeitsvergleich bin ich mal gespannt. Dafür muss ich aber noch ein paar Dinge konfigurieren.
…
Die beiden Systeme sind gefühlt gleich schnell.
Gruß,
Mathias
Die Nextcloud check nur dann ein Verzeichnis, wenn samba mitteilt, dass sich der Inhalt geändert hat.
Wenn also ein Benutzer seine Gruppenzugehörigkeit ändert, ändert das nichts am Inhalt des Tauschverzeichnisses und damit liest NC des Tauschverzeichnisses nicht erneut. Dass sich irgendwelche Berechtigungen geändert haben können, wird dabei ignoriert.
Mein Workaround legt alle 2 Minuten das Verzeichnis nchelper an und alle ungerade Minuten wird es wieder gelöscht. Damit checkt NC jedes mal das Tauschverzeichnis.
Hier meine /etc/cron.d/nchelper :
Mein Workaround legt alle 2 Minuten das Verzeichnis nchelper an und alle
ungerade Minuten wird es wieder gelöscht. Damit checkt NC jedes mal das
Tauschverzeichnis.
Hier meine |/etc/cron.d/nchelper| :
krasse Arbeitsbeschaffungsmaßnahem: 24 Stunden am Tag 5 Tage die Woche …
Bemerkst du da nicht Nebenwirkungen wenn Server und NC andauernd (einmal
pro Minute) beschäftigt werden?
Die Nextcloud ist davon nicht betroffen. Die kriegt nur von samba mitgeteilt, dass sich im Tauschverzeichnis was geändert hat. Und dann liest sie das Verzeichnis ein.
die pädML Linux hat doch optional eine dockerisierte NC-VM, bei der ausschließlich über SMB-Shares gearbeitet wird, sprich, da wird nichts in der NC-VM s gelegt, sondern alle Dateien und Verzeichnisse in der NC sind die Homes und Tauschverheichnisse im päd. Netz.
Ich kann mir nicht vorstellen, dass das ein grundsätzliches Problem sein kann, sonst würde dieses Konzept ja nicht wirklich Sinn machen.
Ich finde das aber mega smart, das muss man dem LMZ an der Stelle lassen.
Mal schauen, ob ich das mit der existierenden NC umgesetzt kriege.
Die LDAP-Einstellungen in der LMZ-NC-VM kenne ich.
Jetzt brauche ich die nötigen LDAP-Daten und Einstellungen in der PädML - das Dauerthema seit 2018.
Die SL hat Anfang März ein Gespräch mit SL, Dienstleister und mir anberaumt mit dem Ziel, eine künftig kooperative Zusammenarbeit zu bewirken. Bislang werde ich vom Dienstleister zwischen ignoriert und von oben herab für zu blöd hingestellt.
Ich bin gespannt…
