Seltsames Ergebnis bei der Synchronisation

Folgendes Szenario
Ein Benutzer A erstellt eine Freigabe und gibt einem anderen Benutzer B Berechtigungen fĂŒr Bearbeiten löschen und erstellen. Ein weiterer Benutzer C erhĂ€lt nur Berechtigungen zum Bearbeiten und Erstellen
Funktioniert einwandfrei ĂŒber die WeboberflĂ€che.
Synchronisiert wird der Cloud Speicherort vom mit dem NextcloudClient. Netzlaufwerk x:\123
Jetzt hat sich aber folgendes ereignet
Benutzer A ist im Urlaub der Client synchronisiert nicht wenn der Benutzer nicht angemeldet ist
Die Dateien die Benutzer B im gleichen ordner angelegt hat werden aber nicht fĂŒr Benutzer C sichtbar
ICh hoffe ich habe mich verstĂ€ndlich ausgedrĂŒckt
und jemand kann mir hierbei helfen

Der Benutzer B ist der EigentĂŒmer der “Neuen” Dateien. Und somit hat nur der Benutzer B die Berechtigung diese fĂŒr den Benutzer C Freizugeben :slight_smile:
Damit er sie sehen kann. UnabhÀngig ob der Benutzer A in Urlaub ist oder nicht.
Wenn der Benutzer B keine Berechtigung hat diese Freizugeben. Muss er diese erst von den Urlauber A bekommen :wink:

Ich glaube @moboter meinte dass A einen Ordner freigegeben hat fĂŒr B mit crud und fĂŒr C mit cru freigegeben. Damit wĂ€re die Erwartung dass alle in diesem Ordner neu erstellte Dateien (egal wer der Author ist: A, B oder andere Benutzer) fĂŒr B **und C sichtbar und bearbeitbar sind


crud = create, read, update, delete

Der Fakt dass A in dem Moment im Urlaub ist, sollte erst mal nebensÀchlich sein - Nextcloud Server sollte die Berechtigungen/Freigaben des Ordners unabhÀngig von dem Desktop Client von A um/durch-setzen.

ich habe es nicht getestet, deswegen reines Gedankenspiel: das erscheint je nach Sichtweise und Erfahrung mit anderen Systemen richtig oder falsch 
 Ich persönlich tendiere zu falsch weil solches Verhalten mehrere unerwartete Effekte nach sich zieht:

  • welche Berechtigung an neuen Files hat A?
  • was passiert wenn A den Ordner löscht?
  • wenn B der Besitzer der Dateien ist werden sie auf die Quota von A oder B angerechnet (A ist der Besitzer des ĂŒbergeordneten Ordner)?

@wwe Absolut korrekt deine Aussage
@Nanu Wenn Benutzer A den Ordner löscht ist er logischerweise fĂŒr alle Weg weil die Freigabe ja von A initiert wurde Das Quota wird auf A angerechnet . A hat als EigentĂŒmer alle Berechtigungen an den Files. Egal von wem sie beigetragen wurden Wir reden ja nicht von Berechtigungen auf Dateiebene sondern von Berechtigungen aus der Datenbank. Der EigentĂŒmer der Datei auf Dateiebene ist Apache

Ich bin mir auch ziemlich sicher, dass das falsch ist. Wenn der Ordner von A freigegeben wurde, gehört er A und alle neuen Dateien die dort abgelegt werden, gehören dem ursprĂŒnglichen Share-Besitzer.

Das erklÀrt allerdings nicht das Verhalten, das der TO beobachtet hat :thinking:

Einfacher Test.
Benutzer C soll eine Datei erstellen. Um zu sehen ob bei B “Sichtbar” sind.

Und ich wĂŒrde in der
Konsole:
php occ db:add-missing-indices
php occ files:scan --all -v
durchlaufen lassen.

Gegenfrage

Wenn root Apache löscht wer ist dann der Besitzer der Datei? :wink:

die Frage ist komplett OT weil es hier um die Applikation Nextcloud geht und nicht darum wie das darunterliegende System mit Dateien umgeht. Ich kann sie trotzdem beantworten: Dateien in einem Unix Filesysystem haben eine numerische ID fĂŒr Besitzer, -gruppe und alle. D.h. wenn ein Benutzer gelöscht wird, bleiben die Dateien im Dateisystem weiterhin der UID des ursprĂŒngliche Besitzer zugeordnet und damit erst mal herrenlos - abhĂ€ngig von Zugriffsrechten der Gruppe oder anderen können entsprechende User oder root darauf zugreifen (um es einfach zu halten ignorieren ich die ACLs).

Deine Frage auf das originale Nextcloud Beispiel ĂŒbertragen wĂŒrde heissen: “A wird als NC Benutzer gelöscht” - und wir haben die Situation dass Dateien im Ordner von A anderen Benutzern zB B gehören; und der Ordner, beim Löschen des Benutzers A ebenfalls gelöscht wird ergeben sich 2 Möglichkeiten:

  • Dateien bleiben “in der Luft” ohne Stammordner hĂ€ngen
  • Dateien von B werden gelöscht - wĂ€re fĂŒr B sicher unerwartet und kommt einem Datenverlust gleicht

Meiner Meinung nach sind beide Varianten unlogisch und unerwartet - ich wĂŒrde beide als Fehler betrachten.

Mir ist das Vollkommen bewusst um welche Dateirechte es hier geht

Und das darunterliegende Dateirechtesystem hat sehr wohl Einfluss auf die darĂŒberliegende Cloud.
Das haben Sie auch selber auch so schön beschrieben.

Deshalb hÀlt aktuell immer noch der Benutzer B die Dateirechte (Ordnerrechte) . Auch wenn es A (Urlauber) nicht gibt.

Nur root könnte der verlorenen Dateirechte (Ordnerrechte) wieder herstellen.
Davon abgesehen schwirren die dateien in /tmp rum auch wenn sie augenscheinlich Gelöscht worden sind.

Meine Frage war rein Obligatorisch um auf die Dateirechte hinzuweisen. Danke fĂŒr die ausfĂŒhrliche ErklĂ€rung :wink:

Wie auch immer. Es wÀre am einfachsten wir warten einfach auf den Urlauber A :slight_smile:

Gute Nacht

das ist im Kontext der Applikation Nextcloud nicht richtig, weil alle Dateien der Applikation im Filesystem des Betriebssystems dem Webserver-Benutzer gehören und nichts mit den Benutzerrechten innerhalb von Nextcloud zu tun haben. Die Benutzer A, B C sind aus Sicht Filesystem nicht existent und haben “ihre” Dateien, Rechte und Freigaben nur innerhalb der Nextcloud. und auch root kann hier nichts machen


ZurĂŒck zum Thema: ich habe (ohne Desktop Sync) getestet was passiert wenn ein User A einen Ordner wie zuerst beschrieben mir 2 weiteren NC usern teilt und diese wiederum Dateien erstellen, verĂ€ndern und umbenennen. So wie meine Erwartung ist können Benutzer B und C die Dateien jeweils sehen und lesen/verĂ€ndern (unabhĂ€ngig ob der Besitzer A eingeloggt ist oder nicht). Die Metadaten zeigen durchaus wer die Datei erstellt hat, es ist aber nicht notwendig dass B und C die neuen Dateien gegenseitig freigeben - diese sind automatisch verfĂŒgbar. Mein Fazit aus dem Test - wenn das beim Sync mit dem Client anders ist wĂŒrde ich zuerst mit dem Web Interface verifizieren dass die Dateien wie erwarten sichtbar sind und anschliessend den Fehler beim Sync suchen (wurde die neue Datei wirklich auf den Server geladen, hat der andere Benutzer den aktuellen Stand usw
)

Ich muss leider noch warten bis der Benutzer A aus seinem Urlaub zurĂŒck ist Vermute aber dass eine Synchronisation von Benutzer A HĂ€ngt und deswegen keine Synchronisation mit den anderen Clients und der Sync Software erfolgt.
Denn wie schon Anfangs erwĂ€hnt klappt es ĂŒber die WeboberflĂ€che

Ich glaube das Mysterium wird klarer nachdem ich den Originalpost das 3. mal gelesen habe.

Ist das so dass B neue Dokumente innerhalb des Netzlaufwerk x:\123 erstellt/editiert?

Wenn das so ist - dann ist es logisch dass die Daten nicht beim Nextcloud Server ankommen (Sync des Benutzer A lĂ€uft nicht wegen Urlaub) und damit fĂŒr C nicht innerhalb der Nextcloud Freigabe sichtbar sind.

Ja aber Benutzer B nutzt auch den Client leider aber mit eigenen Zugangsdaten
Das wirf bei mir die Frage auf was wĂ€re wenn alle Benutzer A und B die gleichen Zugangsdaten benutzen wĂŒrden?

Das ist so nicht ganz richtig.
Da Nextcloud wie jedes Datenbankbasiertes Programm Arbeitet ist es möglich die
den von Root angelegen Benutzer ĂŒber die entsprechende Datanbank zu verwalten. Und Manuell die EintrĂ€ge zu Ă€ndern und den entsprechenden Nextcloudbenutzer zuzu weisen.

Klar geht das. Da auch die GrĂ€te ID’s mitgespeichert werden kann man nachvollziehen wer sich eingeloggt hat. Oder der Betreffende Benutzer hinterlĂ€sst eine Nachricht bei der von ihn Bearbeitenden Datei.

Aber wie schon gesagt. Ich wĂŒrde einfach auf den Urlauber A warten. Das ist der Einfachste weg.

das ist ja absolut richtig und und sollte funktionieren. Entsprechend deiner Beschreibung sollte folgendes passieren:

  • Benutzer B erstellt/Ă€ndert eine Datei im Verzeichnis von A (Freigabe, die lokal syncronisiert wurde)
  • Client von B syncronisiert die Datei zum Server (Datei ist sofort im Webclient sichtbar)
  • C kann die Datei sehen/syncen/bearbeiten

das ist nichts Ausgefallenes und funktioniert im problemlos
 Schaue dir die einzelnen Schritte an - dann wirst du erkennen wo es klemmt und das Problem dort gezielt analysieren.

OK Problem gefunden
Die Snchronisation bei Benutzer A (dem Urlauber) war Fehlerhaft im Sync Client.
Nachdem der Fehler behoben war wurden auch die Dateien die Benutzer B ĂŒber den Client bereitgestellt hat synchronisiert. und hochgeladen.daraufhin wurden alle Dateien fĂŒr Benutzer C sichtbar.