ich bin neu hier und habe es eventuell irgendwo überlesen oder ich habe ein Verständnisproblem. Ich betreibe eine Nextcloud Installation u.a. mit Groupfolders. Darin sind, zumindest in der Weboberfläche, die Benutzerrechte teilweise eingeschränkt. Es gibt z.B. einen Groupfolder, in welchem einer schreiben kann und alle NUR lesen können.
Funktioniert aber nicht im Desktop Client Version 3.9.1 (Windows), hier haben alle immer alle Rechte.
Hallo Mark, wenn es ein Bug ist, dann wundert mich, dass diesen noch niemand anders bemerkt hat. Was ich feststellen kann ist: wenn ich mich als der gleiche Benutzer im Web anmelde, dann stimmen dort die Rechte in den Gruppenordner so, wie ich sie erwarten würde.
Was im Desktop Client richtig ist: wenn der Benutzer überhaupt kein Recht auf einen Ordner hat, dann ist der Ordner auch nicht zu sehen. Aber sobald der Benutzer ein Recht hat, ist es Vollzugriff.
Ich habe auch schon im Internet geforscht, aber entweder ist das Verhalten so gewollt oder ich bin der Einzige, der es falsch macht -)
Anmerkung: Es ist im Client für Android das Gleiche -(
Bist du sicher dass die Änderungen, die ein solcher Benutzer lokal an so einem “read only”-File macht, auch auf den Server zurücksynchronisiert werden? Falls sie nicht zurücksynchronisiert werden, funktioniert meiner Meinung nach alles wie es soll.
ich habe einmal versucht Dein Problem nachzustellen und es funktioniert bei mir so wie es sein soll.
Für den entsprechenden Nutzer wurden unter den erweiterten Berechtigungen nur Leserechte erteilt.
Wenn dieser Nutzer nun versucht eine Datei im Windows-Dateiexplorer zu erstellen, dann wird diese Datei nicht synchronisiert und er erhält sofort eine Fehlermeldung im Desktop-Client. Diese Fehlermeldung erscheint in Abständen immer wieder, bis der Nutzer endlich diese Datei bei sich im Windows-Dateiexplorer entfernt.
In der Nextcloud-Weboberfläche wird dem Nutzer auch die Meldung der fehlenden Berechtigung in dem entsprechenden Ordner angezeigt.
@Crashandy , Hmmh, Frage: Eine Groupfolder, in welchem ein Benutzer Schreibrechte hat und alle anderen nur Leserechte. Der Benutzer mit den Schreibrechten stellt eine Datei ein, die anderen sollen diese nur lesen können.
Im Desktopclient können die nur lesenden Benutzer diese Datei löschen: wo ist da die Logik?
Dein Beispiel scheint mir ausgerichtet aus Sicht des Benutzers, der eine Datei nicht einstellen darf und es auch nicht kann. Aber der gleiche Benutzer kann eine vorhandene Datei löschen, die er nur lesen können soll.
Der Desktop Clinet hat keine Kontrolle darüber was mit der Datei passiert nachdem sie auf den PC synchronisiert wurde. Entscheidend ist, dass sie auf dem Server nicht gelöscht / geändert werden kann. Weder direkt im WebUI, noch via Desktop Client.
Nun hat dieser Benutzer aber irrtümlich eine Datei im Windows-Dateiexplorer erstellt und sieht, dass diese Datei nicht vom Desktop-Client synchronisiert wird. Es kann also kein anderer Benutzer diese Datei sehen, somit kann er diese Datei auch wieder löschen. Bis dahin ist also alles logisch.
Direkt im Webbrowser (ohne diesen Synchronisationsweg) würde es diesem Benutzer erst gar nicht gelingen eine Datei zu erstellen. Hier ist also auch alles logisch.
Eine für den Benutzer mit Leserechten freigegebene Datei kann an keiner Stelle von ihm gelöscht werden, wenn ihm das Löschen verboten ist. Hier funktioniert die Logik auch.
Ergänzung:
Falls der Benutzer eine für ihn bestimmte Datei löschen würde, dann synchronisiert der Desktop-Client diesen Ordner wieder und die gelöschte Datei ist plötzlich wieder da.
Jup, sollte sich bei Gruppenordnern eigentlich so verhalten (laut Logik) Bei normalen Shares wird die Datei in so einem Fall einfach “un-shared”, sprich die Datei ist dann nicht mehr mit diesem Benutzer geteilt.
Danke für eure Antworten -). Ich akzeptiere mal eure Sicht der Dinge und werde mal testen. Eure Erläuterungen,danke auch @bb77, helfen mir da echt weiter. Ich kann gut damit leben, dass der Client das alles selbst regelt. Wenn die Software das Abseits der ACL macht, dann ist das auch ok für mich.
Ich habe die Antwort von @Mornsgrans als Lösung gewählt. @bb77 und @Crashandy : Eure Ansätze führen auch zur Lösung, musste mich für eine Lösung entscheiden -)
.
