Serie: Ralf regt sich auf über Nextcloud-Synchronisation

  Ralf Hersel   Lesezeit: 4 Minuten  🗪 12 Kommentare Auf Mastodon ansehen

Ich versuche verzweifelt, eine Datei aus einer lokalen Nextcloud-Synchronisation zu löschen. Dabei entdecke ich die Ursache und kann sie nicht beheben.

serie: ralf regt sich auf über nextcloud-synchronisation

Weiter geht es mit der Aufreger-Serie. Dieses Mal geht es um die Dateisynchronisation zwischen der Nextcloud und dem lokalen PC. Vermutlich habe ich gar keinen Grund, mich aufzuregen, weil ich den Stein des Anstosses nur auf einer Nextcloud reproduzieren kann, jedoch nicht auf einer anderen Instanz. Es geht auch nicht generell um die Synchronisation, sondern nur um einen speziellen Fall.

Bevor das Gejammer beginnt, möchte ich vorab sagen, dass ich meine Nextcloud liebe, seit Jahren nutze und sehr zufrieden damit bin. Ich nehme an, dass der Effekt, den ich gleich beschreiben werde, auf einen Konfigurationsfehler oder eine bestimmte Einstellung zurückzuführen ist. Doch worum geht es?

Gelöschte Dateien erscheinen sofort wieder

Ich habe über den Nextcloud-Sync-Client zwei Nextcloud-Instanzen auf meinen Rechnern eingebunden: meine private und die von GNU/Linux.ch (GL). Mit der Privaten kann ich das Problem nicht reproduzieren. Doch wenn ich bei der GL-Anbindung eine Datei lokal lösche, verschwindet sie, um zwei Sekunden später wieder zu erscheinen:

Der Effekt Schritt für Schritt:

  1. Ich lösche die Datei delme.md im lokal synchronisierten Nextcloud-Verzeichnis
  2. Die Datei verschwindet,
  3. um zwei Sekunden später wieder im Verzeichnis zu erscheinen.

Diesen Effekt kann ich mit jeder Datei und in jedem Verzeichnis reproduzieren. Wie zuvor erwähnt, passiert das nur mit der GL-Nextcloud, jedoch nicht bei meiner privaten Nextcloud. Beim Erstellen einer neuen Datei im lokal synchronisierten Ordner, tritt dieser Effekt nicht auf; nur beim Löschen

Ursachenforschung

Woran könnte das liegen? Mir kamen mehrere Ursachen in den Sinn:

  1. Die Einstellungen (für die zwei Nextcloud-Einbindungen) im Nextcloud-Sync-Client könnten unterschiedlich sein. Das habe ich überprüft und konnte keine Unterschiede feststellen.

  2. Die Zeitstempel auf dem Server könnten falsch sein. Falls diese auf dem Server zeitlich in der Zukunft liegen, würde die Synchronisation die lokal gelöschte Datei als älter erkennen und durch die neuere Version vom Server ersetzen. Doch daran liegt es nicht; die Zeitstempel (lokal und serverseitig) sind identisch.

  3. Die Ursache könnte in den Zugriffsrechten auf die Nextcloud liegen. Im Gegensatz zu meiner privaten Nextcloud, bin ich bei der GL-Nextcloud nicht als Admin, sondern als normaler User angemeldet. Das ist eine heisse Spur. Tatsächlich habe ich im Web-Interface der GL-Nextcloud nicht das Recht, eine Datei zu löschen:


    Für die Datei text.txt steht für einen normalen User keine Löschoption zur Verfügung.

Bingo, ich habe die Ursache gefunden. Wie man in der letzten Bildschirmaufnahme sieht, wurde das Verzeichnis von Admin (A) geteilt, wodurch offensichtlich die Rechte zur Bearbeitung (Löschen) einer Datei eingeschränkt sind. Nun werfe ich einen Blick auf die Nextcloud-Konten:

Zugegeben, hier müssen wir ohnehin einmal aufräumen. Bei den Benutzerkonten kann man keine Rechte einstellen; diese geschieht über die zugeordneten Gruppen. Davon gibt es zwei: Core und Admin. Ausserdem kann man Gruppenadministrator-Rechte vergeben und Manager für Gruppen zuordnen. Die Stelle, an der man einstellen kann, welche Rechte welche Gruppe hat, habe ich leider nicht gefunden.

Aber Ralf, read the fucking manual!

Verzweiflung

Ja, ich habe das Manual zum Thema User und Group Management gelesen. Schlauer war ich danach nicht. Nach einer weiteren halben Stunde Aktenstudium, war ich der Überzeugung, dass man die Dateirechte durch die Freigabe-Optionen auf einem Verzeichnis regeln kann. Deshalb habe ich meinem User (als Admin angemeldet) benutzerdefinierte Berechtigungen gegeben:

Dreimal dürft ihr raten, ob ich die Datei nach dieser Anpassung lokal löschen konnte. Nein, konnte ich nicht. Und jetzt bin ich mit meinem Latein am Ende und rege mich auf. Bin ich zu blöd, oder ist die Rechteverwaltung in der Nextcloud wirklich so kompliziert und unverständlich?

Ich hoffe auf eure klärenden Kommentare.

Nachtrag

Vielen Dank für eure Kommentare. Sie beinhalten zwar nicht unmittelbar die Lösung zum beschriebenen Problem, bestätigen jedoch weitgehend meine Vermutung, dass es an der Rechtevergabe liegt. Da ich bisher nicht ganz durchblicke, wie diese funktioniert, werde ich mich dieser Thematik in einem eigenen Artikel annehmen. Mein Eindruck ist, dass ich nicht der Einzige bin, der damit Verständnisschwierigkeiten hat. Deshalb möchte ich mit dem neuen Artikel ein wenig zur Aufklärung beitragen.

Titelbild: https://pixabay.com/vectors/computer-keys-pra%c3%a7a-delete-key-644457/

Quelle: https://docs.nextcloud.com/server/stable/admin_manual/configuration_user/user_configuration.html

Tags

Nextcloud, Synchronisation, Gruppen, Rechte

Robert
Geschrieben von Robert am 17. Februar 2026 um 09:29

Vermutlich nicht die Lösung, aber mein erster Gedanke: Vielleicht lädt ein anderer Computer mit einer scheinbar hohen Synchronisationsfrequenz sie immer gleich wieder hoch?

Atalanttore
Geschrieben von Atalanttore am 17. Februar 2026 um 09:35

Mein Syncthing synchronisiert absolut zuverlässig.😁

Bubi
Geschrieben von Bubi am 18. Februar 2026 um 08:37

Danke, läuft hervorragend unter Fedora Silverblue. Nextcloud-Client ist geschichte. Endlich weg von QT.

Lars Müller
Geschrieben von Lars Müller am 17. Februar 2026 um 10:23

Hallo Ralf,

Man kann anscheinend keine Gruppe anpassen, auch als Admin nicht. Zumindest habe ich den Punkt nicht gefunden in meiner Cloud.

Das ist natürlich nicht schön

Peter Silie
Geschrieben von Peter Silie am 17. Februar 2026 um 10:29

Meine Hoffnung liegt bei OpenCloud und deren Nutzung von JMAP als Ersatz für die ganzen DAV-Protokolle. Auf der FOSDEM-Seite finden sich einige ganz interessante Videos dazu https://fosdem.org/2026/schedule/tracks/

Daniel XAG.info
Geschrieben von Daniel XAG.info am 17. Februar 2026 um 10:34

Irgendeine Stelle in eurer Cloud ist der Meinung, dass diese Datei dort hingehört und repliziert sie daher — its a feature, not a bug. Kürzlich hatte eine Kundin ein ähnliches Problem. Da lag es daran, dass die Freigabe, in der das Phänomen auftauchte, auf einem Client mit Admin-Rechten ein weiteres mal freigegeben war. Keine Ahnung, warum man sowas macht. Das zu finden, hat ein paar Stunden gedauert.

Ingo
Geschrieben von Ingo am 17. Februar 2026 um 11:01

Moin,

ggf. - ich habe es noch nicht getestet

  1. Avatar anklicken
  2. Administratoreinstellungen
  3. Teilen
  4. Scrollen bis "Standardberechtigungen für das Teilen"

Ingo

Ingo
Geschrieben von Ingo am 17. Februar 2026 um 11:11

... und nocheinmal ich ...

Es könnte natürlich auch an den Freigabeeigenschaften des entsprechenden Ordners liegen. Dort kann man ja auch festlegen, wer was darf.

Ich bin schon zwei Jahre raus, aber so hatte ich das gelöst: Gruppe angelegt, Nutzer zugeordnet, Ordner freigeben an eine Gruppe und da bei festlegen, was die Guppe darf.

Ingo

faloz
Geschrieben von faloz am 17. Februar 2026 um 21:29

Stimmen die Rechte im Dateisystem, dass der Server überhaupt löschen kann? /www-data, acl Berechtigungen) Erzeugte Dateien setzen evtl. über unterschiedliche Wege auch unterschiedliche Rechte.

Die Dateien wurden evtl. in der Table "oc_file_locks" gesperrt?

Armakuni
Geschrieben von Armakuni am 18. Februar 2026 um 06:39

Ich würde sie als der Dateibesitzer ansteuern und löschen.

Alternativ würde ich die Datei auf dem Computer mal mit touch aktualisieren und schauen, ob er dieses "Update" synct. Wenn ja, dann danach am gleichen Computer löschen.

Wenn das immer noch nicht hilft, mal via SSH auf dem Nextcloud Server anmelden und als root in den data Ordner schauen. Evtl. stimmen die Rechte hier nicht? Alternativ hier dann die Datei einfach löschen...

gryps
Geschrieben von gryps am 19. Februar 2026 um 12:00

Hast du es schon mal auf dem Datenbankniveau versucht? Ich kann manchmal Dateien nicht löschen, die jemand anders in der Familie im geteilten Ordner erstellt hat. Die Lösung ist dann die entsprechende Zeile in der Tabelle file_lock (oder so ähnlich, kann gerade nicht nachsehen) zu löschen. Ich selbst mache dann immer radikal DELETE * FROM file_lock WHERE 1 Aber das ist mein eigenes Risiko 😁

Christian
Geschrieben von Christian am 14. März 2026 um 11:37

Hallo Ralf,

ich hatte das gleiche Problem und die Suche hat mich hierher geführt. Danke fürs Aufschreiben!

Die Lösung war für mich in den Einstellungen zum Gruppenordner (als Admin -> Verwaltungseinstellungen > Gruppenorder): Dort in der Liste der Ordner auf die Spalte Gruppe auf die Gruppe klicken, dann geht ein Fenster auf, in dem die Schreib- und Leserechte eingestellt werden können.

Nachdem ich den Haken bei Löschen wieder ergänzt hatte, klappte alles wie erwartet.