Umbenannt, verschoben, verwechselt: Wie Nextcloud mit Freigabenamen umgeht

Es gibt diese Momente in der Administration, in denen man denkt, ein Problem sei längst gelöst – und dann steht man vor einem Dateibaum, in dem derselbe Ordner bei fünf Kollegen fünf verschiedene Namen trägt. „Projekt Nord“, „Projekt_Nord_alt“, „Nord (final)“ und irgendwo dazwischen ein Eintrag, der schlicht „Dokumente“ heißt, weil ihn irgendwann jemand schnell umgetauft hat. Der Eigentümer sieht davon nichts. In seinem Nextcloud-Konto existiert genau ein Ordner mit genau einem Namen. Alle anderen Schreibweisen leben ausschließlich in den Ansichten der Empfänger.

Was auf den ersten Blick wie ein Kosmetikproblem wirkt, ist in Wirklichkeit einer der am häufigsten unterschätzten Mechanismen in Nextcloud. Denn das Umbenennen einer Freigabe ist etwas grundlegend anderes als das Umbenennen einer Datei. Wer diesen Unterschied nicht kennt, produziert im besten Fall Verwirrung im Helpdesk, im schlechteren Fall doppelte Synchronisationspfade, verwaiste Mounts und Support-Tickets, die wochenlang durch die Gegend wandern. Dieser Beitrag versucht, das Thema von der Datenbank bis zur Benutzeroberfläche aufzurollen – inklusive der Stellen, an denen es bis heute weh tut.

Drei Namen für ein und dieselbe Sache

Um zu verstehen, was beim Umbenennen passiert, hilft eine simple Trennung. Jedes geteilte Objekt in Nextcloud trägt potenziell drei Namen gleichzeitig.

Der erste ist der Dateiname im Speicher des Eigentümers. Er steht im Konto desjenigen, dem die Datei oder der Ordner gehört, und er ist der einzige Name, der tatsächlich physikalisch beziehungsweise im zugrunde liegenden Objektspeicher existiert. Ändert der Eigentümer ihn, ändert sich der Name für alle, die noch keine eigene Bezeichnung vergeben haben.

Der zweite ist der Zielname der Freigabe, in der Datenbank als file_target geführt. Das ist der Pfad, unter dem eine eingehende Freigabe im Konto des Empfängers eingehängt wird. Genau hier lebt der Name, den ein Empfänger sieht, wenn er im eigenen Dateibaum auf den geteilten Ordner blickt.

Der dritte ist der Anzeigename im Kontext der jeweiligen Oberfläche – also das, was in einer Verknüpfung, in einer Suche, in einem Kalenderanhang oder im Desktop-Client als Zeichenkette auftaucht. Dieser dritte Name ist keine eigene Entität, sondern immer eine Ableitung aus einem der beiden ersten. Trotzdem wird er in der Praxis häufig mit dem Original verwechselt, weil die Oberflächen den Unterschied nicht sichtbar machen.

Das klingt akademisch, hat aber unmittelbare Folgen. Ein Beispiel: Eine Marketingabteilung teilt den Ordner Kampagne 2025 mit der Agentur. Der Agentur-Kontakt findet den Ordner in seinem Nextcloud-Konto. Weil er parallel an fünf Kunden arbeitet, benennt er ihn um in Kunde Müller – Kampagne. Der Marketing-Leiter sieht davon nichts. In seinem Konto heißt der Ordner weiterhin Kampagne 2025. Dasselbe Objekt, zwei Namen. Und das ist kein Fehler, sondern genau die Funktion.

Was die Datenbank daraus macht

Ein Blick unter die Haube lohnt sich, weil er viele Merkwürdigkeiten erklärt. Freigaben liegen in Nextcloud in der Tabelle oc_share. Dort stehen pro Datensatz unter anderen die Spalten share_type, uid_owner, uid_initiator, share_with, item_source, file_source, file_target, permissions und accepted.

Entscheidend ist die Trennung zwischen file_source und file_target. file_source ist die interne Datei-ID – also der Zeiger auf den tatsächlichen Knoten im Dateicache, unabhängig davon, wie er gerade heißt. Diese ID bleibt über Umbenennungen hinweg stabil. file_target dagegen ist der Pfad, unter dem die Freigabe im Heimverzeichnis des Empfängers erscheint, üblicherweise beginnend mit einem Schrägstrich, etwa /Kunde Müller – Kampagne.

Wer sich das einmal klargemacht hat, versteht sofort, warum das Umbenennen einer eingehenden Freigabe praktisch keine Daten bewegt. Es wird kein Byte kopiert, kein Download ausgelöst, keine Datei neu geschrieben. Es ändert sich ein Feld in einer Datenbankzeile und in der Folge der Eintrag in der Mount-Tabelle des jeweiligen Nutzers. Der Rest der Welt merkt nichts davon.

Ein zweiter technischer Punkt: Die Datei-ID bleibt gleich, und das ist für Automatisierung ausgesprochen angenehm. Skripte, die sich auf die fileid oder die Share-ID stützen, überleben jede Umbenennung. Wer dagegen Pfade als Referenz speichert, läuft in genau die Fallen, die später noch beschrieben werden.

Die Bedienung im Alltag – zwei Perspektiven

Für den Eigentümer ist die Sache unspektakulär. Er markiert die Datei oder den Ordner und wählt im Kontextmenü „Umbenennen“. In der aktuellen Oberfläche ist das kein Sonderfall für Freigaben, sondern schlicht eine Umbenennung wie jede andere. Konsequenz: Der file_source bleibt, der Name ändert sich, und alle Empfänger, die noch keinen eigenen Zielnamen gesetzt haben, sehen den neuen Namen. Wer bereits umbenannt hat, behält seine eigene Bezeichnung.

Für den Empfänger ist die Lage differenzierter. Er sieht eine eingehende Freigabe in seinem Dateibaum, oft mit einem kleinen Freigabe-Symbol versehen. Wählt er dort „Umbenennen“, wird nicht die Datei des Eigentümers umbenannt, sondern ausschließlich sein eigener Mountpunkt. In modernen Versionen ist das sauber implementiert: Die Freigabe wird über einen internen Mount-Mechanismus abgebildet, und eine Umbenennung dieses Mountpunkts aktualisiert lediglich das file_target. Der Eigentümer bekommt davon nichts mit, und das ist auch gut so.

Allerdings: Über die Versionsgrenzen hinweg war das nicht immer so. Wer ältere Instanzen betreut oder Upgrade-Pfade über mehrere Major-Versionen plant, sollte sich nicht blind darauf verlassen, dass jede Umbenennung immer lokal bleibt. Ein Test in einer Staging-Umgebung kostet zwanzig Minuten und erspart im Zweifel eine unangenehme E-Mail an den Dateneigentümer.

Ein interessanter Aspekt ist in diesem Zusammenhang die Frage, ob auch Empfänger reiner Lesefreigaben umbenennen dürfen. Die Berechtigungsmaske einer Freigabe beschreibt Bit für Bit, was mit dem Inhalt geschehen darf – Lesen, Ändern, Anlegen, Löschen, Weiterteilen. Das Umbenennen des Mountpunkts ist aber streng genommen keine Inhaltsänderung. In der Community wird diese Frage seit Jahren diskutiert, und die Antwort fällt je nach Version und je nach Rechtezusammensetzung unterschiedlich aus. Administratoren, die hier klare Verhältnisse brauchen, kommen um eigene Tests nicht herum.

Freigabename versus Standardsortierung

Ein verwandter Mechanismus, der regelmäßig für Verwirrung sorgt, ist der share_folder. Diese Systemeinstellung legt fest, in welchem Ordner eingehende Freigaben standardmäßig landen. Ohne Konfiguration erscheinen sie direkt im Wurzelverzeichnis des Nutzers. Wer in größeren Umgebungen arbeitet, setzt hier häufig einen Standartordner wie /Freigaben oder /Shared, damit der eigene Dateibaum übersichtlich bleibt.

Wichtig zu wissen: Diesen Vorgabepfad setzt der Administrator, er ist keine Eigenschaft der einzelnen Freigabe. Ein Empfänger kann den Mountpunkt danach beliebig verschieben oder umbenennen; die Konfiguration greift nur beim erstmaligen Einhängen. Das führt in der Praxis gelegentlich zu dem Effekt, dass ältere Freigaben noch im Wurzelverzeichnis liegen, während neue im Freigabeordner auftauchen – ein Zustand, den man besser dokumentiert, bevor die ersten Tickets eintreffen.

Es gibt noch eine Besonderheit, die in diesem Umfeld immer wieder auftaucht: In jüngeren Releases wurde darüber diskutiert, ob nicht der Eigentümer beim Teilen einen abweichenden Freigabenamen vorgeben sollte – also ein Feld, in dem er bestimmt, unter welcher Bezeichnung die Freigabe beim Gegenüber erscheint. Die Anforderung ist alt, die Umsetzung je nach Release-Stand unterschiedlich weit gediehen. Wer darauf planerisch aufbauen will, prüft die eigene Version und verlässt sich im Zweifel lieber auf eine klare Namenskonvention im Originalnamen.

Gruppenfreigaben, Mehrfachfreigaben, Sonderfälle

Spannend wird es, wenn ein Objekt an mehrere Empfänger gleichzeitig geht. Teilt man einen Ordner an eine Gruppe, existiert dafür genau ein Freigabedatensatz. Beim Einhängen entsteht jedoch pro Nutzer ein eigener Mountpunkt mit eigenem file_target. Das bedeutet: Fünfzehn Gruppenmitglieder können fünfzehn verschiedene Namen für dieselbe Sache sehen, ohne dass sich irgendetwas gegenseitig überschreibt. Aus Sicht der Datenhaltung ist das elegant. Aus Sicht der Kommunikation ist es eine Zumutung, wenn der Helpdesk anonyme Anrufe der Art „Ich finde den Ordner nicht“ beantworten muss.

Werden zwei verschiedene Freigaben mit demselben Zielnamen an denselben Nutzer geschickt, greift automatisch eine Suffix-Logik. Der zweite Eintrag landet dann als /Projekte (2) im Dateibaum. Das ist funktional korrekt und trotzdem ein häufiger Auslöser für Verwirrung, weil der Nutzer nicht erkennen kann, welche der beiden Versionen die aktuelle ist. Abhilfe schafft hier nur Disziplin bei der Benennung oder eine aktive Nachfrage beim Absender.

Bei der App Groupfolders verschiebt sich die Logik noch einmal. Gruppenordner sind keine klassischen Freigaben, sondern administrativ zugewiesene Mounts mit eigener Rechteverwaltung. Der Name des Mountpunkts wird hier nicht vom einzelnen Nutzer festgelegt, sondern ergibt sich aus der Konfiguration des Gruppenordners. Umbenennen im Dateibaum ist entsprechend nicht vorgesehen beziehungsweise wird gar nicht erst angeboten. Wer aus einer klassischen Freigabe in einen Gruppenordner migriert, sollte das im Vorfeld klar kommunizieren, weil die Nutzer genau diese Freiheit verlieren.

Föderierte Freigaben – also Freigaben zwischen zwei Nextcloud-Instanzen – funktionieren im Kern ähnlich, haben aber eine zusätzliche Bruchstelle: Auf der lokalen Seite wird ein Mountpunkt angelegt, dessen Name aus der Remote-Freigabe abgeleitet wird. Der Empfänger kann ihn lokal umbenennen. Ändert allerdings die Gegenseite den Originalnamen, kann es Konstellationen geben, in denen der lokale Name bestehen bleibt und die beiden Seiten dauerhaft unterschiedlich heißen. Das ist kein Datenverlust, aber ein Klassiker für Rückfragen.

Externe Speicher, etwa per SMB oder WebDAV eingebundene Ablagen, folgen wieder anderen Regeln. Der Mountpunkt wird administrativ definiert, und ein Umbenennen im Dateibaum hätte hier potentiell Rückwirkungen auf die Konfiguration – deshalb ist die Aktion in der Regel gesperrt oder wird serverseitig ohnehin ignoriert. Auch das ist ein Punkt, der in Schulungsunterlagen gehört.

Link-Freigaben: keine Namen, aber Konsequenzen

Bei öffentlichen Links stellt sich die Frage in anderer Form. Ein Link hat keinen eigenen Namen. Er ist eine Zeichenkette, die auf eine file_source zeigt, und er bleibt gültig, egal wie oft die dahinterliegende Datei umbenannt wird. Das ist eine der angenehmsten Eigenschaften des Systems: Wer einmal einen Link in einem Angebot, auf einer Website oder in einer E-Mail verteilt hat, muss sich keine Sorgen machen, dass eine Umbenennung ihn zerstört.

Was sich sehr wohl ändert, ist das, was der Empfänger des Links sieht. Der öffentliche Download zeigt den aktuellen Dateinamen an. Wird ein Ordner als ZIP heruntergeladen, trägt das Archiv den aktuellen Namen. Wird eine Datei umbenannt, erscheint sie im Browser unter dem neuen Namen. Wer also einen Link zu einem Dokument mit dem Namen Angebot_Entwurf_v3.docx verschickt und diesen später in Angebot_2025_final.docx umbenennt, verbessert damit nachträglich den Auftritt – ohne den Link anfassen zu müssen. In der Praxis wird das erstaunlich selten genutzt.

Zusätzlich gibt es bei Link-Freigaben Metadaten, die den Kontext liefern: eine Notiz für den Empfänger, ein Ablaufdatum, ein Passwort, gegebenenfalls feste Rechte. Diese Angaben hängen an der Freigabe, nicht am Dateinamen. Sie überleben eine Umbenennung ebenfalls unbeschadet.

Wenn der Eigentümer umbenennt – ein unterschätzter Fall

Der umgekehrte Weg ist der eigentlich brisante. Der Eigentümer benennt einen Ordner um, der an zwanzig Personen geteilt ist. Was passiert?

Für alle Empfänger, die den Mountpunkt nie angefasst haben, ändert sich der sichtbare Name mit. Das ist bequem und meist gewünscht. Für alle, die ihren Mountpunkt individuell umbenannt haben, bleibt der eigene Name bestehen – solange die Implementierung die Zielangabe als bewusst gesetzten Wert behandelt. Diese Unterscheidung ist sinnvoll, sie führt aber zu einem Zustand, in dem ein Teil des Teams die Änderung mitbekommt und ein anderer nicht. Kommunikation ist hier kein Nice-to-have, sondern Betriebsnotwendigkeit.

Kritischer wird es, wenn ein übergeordneter Ordner umbenannt wird, in dem sich mehrere Freigaben befinden. Auch wenn die einzelnen Freigaben weiterhin funktionieren, verändern sich die angezeigten Pfade. Und wer in Skripten, Verknüpfungen oder Dokumentationen mit absoluten Pfaden arbeitet, muss diese überall nachziehen. Deshalb gilt eine einfache Regel: Freigaben möglichst weit oben im Baum anlegen und die darunterliegende Struktur stabil halten. Umbenennungen sollten die Ausnahme sein, nicht die Regel.

Rechte, Weiterteilen und die Grenzen der Kulanz

Ein Wort zur Berechtigungsmaske, weil sie im Zusammenhang mit Umbenennungen immer wieder falsch interpretiert wird. Nextcloud arbeitet mit einer bitweisen Rechtevergabe. Lesen ist eins, Ändern zwei, Anlegen vier, Löschen acht, Weiterteilen sechzehn. Die Summe einunddreißig entspricht allen Rechten. Eine Lesefreigabe hat genau ein Bit gesetzt.

Das Umbenennen des Mountpunkts durch den Empfänger ist in dieser Logik ein Sonderfall, weil es die Datei selbst nicht berührt. Je nach Version und Konstellation ist es auch bei reinen Lesefreigaben möglich oder eben nicht. Wer eine verbindliche Aussage für seine Umgebung braucht, sollte die Frage in einem Testsystem mit exakt derselben Version und denselben Apps nachstellen. Das gilt umso mehr, wenn Apps wie Secure View oder Wasserzeichen-Funktionen im Spiel sind, die zusätzliche Einschränkungen mitbringen und die Oberfläche entsprechend verändern.

Ein verwandter Punkt ist das Weiterteilen. Erlaubt man Empfängern, eine Freigabe weiterzureichen, entstehen schnell Ketten, in denen der ursprüngliche Eigentümer den Überblick verliert. Die Namen in diesen Ketten folgen keiner gemeinsamen Logik, weil jeder Beteiligte seinen eigenen Mountpunkt pflegt. Wer das vermeiden will, schränkt das Weiterteilen ein und arbeitet stattdessen mit Gruppenfreigaben oder Gruppenordnern.

API, Kommandozeile und Automatisierung

Für Administratoren interessant ist der Zugang abseits der Oberfläche. Die Share-Verwaltung läuft über die OCS-API. Eine Liste der Freigaben, die man selbst erhalten hat, lässt sich so abrufen:

curl -u benutzer:passwort \
  -H "OCS-APIRequest: true" \
  "https://cloud.example.org/ocs/v2.php/apps/files_sharing/api/v1/shares?shared_with_me=true&format=json"

In der Antwort tauchen pro Freigabe unter anderem ein path-Feld und ein file_target-Feld auf. Wichtig ist die Unterscheidung: Der path beschreibt den Ort relativ zum Wurzelverzeichnis des Eigentümers, der file_target dagegen den Pfad relativ zum eigenen Wurzelverzeichnis. Für Skripte, die den eigenen Mountpunkt kennen müssen, ist damit das zweite Feld die relevante Größe – eine Unterscheidung, die in vielen selbstgebauten Werkzeugen falsch umgesetzt ist.

Um den Zielnamen zu verändern, lässt sich derselbe Endpunkt mit einer PUT-Anfrage ansprechen. Die Semantik hat sich über die Release-Generationen verschoben, in der Praxis läuft es auf den Parameter path hinaus, der auf den gewünschten Zielnamen gesetzt wird. Weil die Details versionsabhängig sind, gehört ein kurzer Testlauf in die eigene Umgebung, bevor man so etwas in ein Produktionsskript gießt.

curl -X PUT -u benutzer:passwort \
  -H "OCS-APIRequest: true" \
  -d "path=/Neuer Zielname" \
  "https://cloud.example.org/ocs/v2.php/apps/files_sharing/api/v1/shares/4711"

Auf Dateiebene funktioniert derselbe Vorgang über WebDAV. Ein MOVE auf einen Mountpunkt benennt in aktuellen Versionen ausschließlich den Zielnamen um, nicht die dahinterliegende Datei. Das Protokoll liefert dabei weiterhin die stabile Datei-ID im Header OC-FileId mit, was die oben beschriebene Trennung sehr schön sichtbar macht.

curl -X MOVE -u benutzer:passwort \
  -H "Destination: https://cloud.example.org/remote.php/dav/files/benutzer/NeuerName" \
  -H "Overwrite: F" \
  "https://cloud.example.org/remote.php/dav/files/benutzer/AlterName"

Auf Serverseite gibt es daneben eine Reihe von occ-Befehlen, die im Umfeld von Freigaben regelmäßig gebraucht werden. Der Dateiscanner ist der bekannteste, er synchronisiert den Dateicache mit dem, was tatsächlich auf dem Datenträger liegt. Die Konfigurationsabfrage zeigt, welcher Standardordner für eingehende Freigaben gesetzt ist. Und die Reparaturroutine stößt eine Reihe von Wiederherstellungsschritten an, unter denen sich auch solche befinden, die sich mit dem Zustand von Freigabezielen befassen.

sudo -u www-data php occ config:system:get share_folder
sudo -u www-data php occ files:scan --path="/benutzer/files"
sudo -u www-data php occ maintenance:repair

Wer zur Diagnose direkt in die Datenbank schaut, kann sich mit einer reinen Leseabfrage einen Überblick verschaffen. Schreibende Eingriffe in oc_share sollten dagegen tabu sein – der Dateicache und die Mount-Verwaltung halten eigene Zustände, die man damit zuverlässig aus dem Tritt bringt.

SELECT id, share_type, uid_owner, file_source, file_target, permissions
FROM oc_share
WHERE share_with = 'kollege' AND share_type = 0;

Was der Sync-Client daraus macht

Spätestens beim Desktop-Client wird das Thema praktisch. Der Client synchronisiert lokale Ordner mit den Einträgen im Konto. Wird ein Mountpunkt umbenannt, taucht das im Client als Verschiebevorgang auf – nicht als Neu-Download. Das ist effizient, kann aber in zwei Konstellationen unangenehm werden.

Die erste betrifft Dateisysteme, die Groß- und Kleinschreibung nicht unterscheiden. Auf Windows und in der Standardkonfiguration von macOS sind Projekt und projekt derselbe Pfad. Eine Umbenennung, die nur die Schreibweise ändert, führt dort regelmäßig zu Fehlermeldungen und in ungünstigen Fällen zu widersprüchlichen Zuständen zwischen Server und Client. Die zweite betrifft gesperrte Dateien. Wird gerade eine Datei im umzubenennenden Ordner geöffnet gehalten, scheitert die lokale Umbenennung, und der Client meldet einen Konflikt, obwohl auf Serverseite alles korrekt ist.

Wer in gemischten Umgebungen arbeitet, tut gut daran, Umbenennungen auf Ordner zu beschränken, die nicht gerade in Benutzung sind, und reine Schreibweisenänderungen nach Möglichkeit zu vermeiden. Der zweite Rat gilt übrigens auch für Dateinamen mit Sonderzeichen und für die klassischen Windows-Reservierten wie CON, PRN oder AUX. Sie funktionieren serverseitig, brechen aber auf der Clientseite.

Typische Fehlerbilder und ihre Ursachen

In der Praxis begegnet man einer Handvoll wiederkehrender Symptome, die fast immer auf dieselben Ursachen zurückgehen.

Da ist zunächst der Empfänger, der eine Freigabe umbenennt und anschließend feststellt, dass sie in einem anderen Kontext plötzlich wieder anders heißt. Ursache ist meist ein zweiter Zugriffspfad – etwa ein zusätzlicher Mount über eine andere Freigabe oder ein Gruppenordner, der auf dasselbe Verzeichnis zeigt. Das Objekt ist identisch, die Anzeigenamen unterscheiden sich.

Dann gibt es den Fall, dass ein Umbenennen im Browser scheinbar wirkungslos bleibt. Das passiert häufig, wenn die Seite aus dem Cache geladen wurde oder wenn ein Skript die Änderung über die API vorgenommen hat und die Oberfläche noch auf dem alten Stand ist. Ein Neuladen der Ansicht klärt das in der Regel.

Häufig sind auch verwaiste Mounts: Freigaben, deren Zielname auf einen Pfad zeigt, den es so nicht mehr gibt, weil zwischenzeitlich im eigenen Baum verschoben wurde. Hier hilft der Dateiscanner in Kombination mit einer gezielten Prüfung der betroffenen Freigaben über die API. In hartnäckigen Fällen kann auch die Reparaturroutine den Zustand wieder geraderücken.

Und schließlich der Klassiker, der keiner Fehlerbehebung bedarf: Zwei Nutzer streiten darüber, wie ein Ordner heißt. Der eine hat recht, der andere auch. Es ist derselbe Ordner mit zwei Zielnamen. Der Helpdesk kann an dieser Stelle viel Zeit sparen, wenn er diesen Mechanismus kennt und erklärt, statt nach einer Ursache zu suchen, die es nicht gibt.

Betriebliche Regeln statt Benutzererziehung

Aus all dem folgt, dass Umbenennungen im Freigabekontext weniger ein technisches als ein organisatorisches Thema sind. Technisch funktioniert es. Die Frage ist, ob die Organisation damit umgehen kann.

Ein paar Regeln haben sich bewährt. Erstens: Freigaben so weit oben im Baum wie möglich anlegen und darunter nicht mehr umbenennen. Zweitens: Namenskonventionen dokumentieren und durchsetzen, statt auf Zurufe zu hoffen. Drittens: Empfänger ausdrücklich darüber informieren, dass ein Umbenennen nur die eigene Ansicht betrifft – dieser Satz gehört in jede Einführungsschulung. Viertens: Umbenennungen des Eigentümers ankündigen, wenn mehr als eine Handvoll Personen betroffen ist.

Für Umgebungen mit vielen Freigaben lohnt sich außerdem ein prüfendes Skript, das regelmäßig über die API die empfangenen Freigaben auflistet und Abweichungen zwischen Originalname und Zielname sichtbar macht. Solche Abweichungen sind nicht per se schlecht, aber sie sollten bekannt sein. Wer sie kennt, kann entscheiden, ob sie gewollt sind.

Nicht zuletzt spielt die Frage in Audit- und Compliance-Kontexten eine Rolle. Eine Umbenennung ändert keine Zugriffsrechte, sie erzeugt keine neuen Freigaben und sie verschiebt keine Daten über Organisationsgrenzen. Die Share-ID bleibt stabil. Für Prüfpfade ist das eine gute Nachricht: Ein Umbenennungsvorgang lässt sich sauber nachvollziehen, ohne dass danach die gesamte Freigabehistorie neu bewertet werden muss. In Häusern, die mit einer Audit-App arbeiten, tauchen diese Vorgänge entsprechend als eigene Ereignisse auf.

Ein Blick nach vorn

Nextcloud hat in den vergangenen Jahren viel Arbeit in die Oberfläche der Dateiverwaltung gesteckt, und die Freigabelogik ist dabei mitgewachsen. Der Umgang mit Mountpunkten ist heute deutlich konsistenter als noch vor einigen Jahren, und die Trennung zwischen Objektname und Anzeigename ist zumindest im Backend sauber vollzogen.

Was weiterhin fehlt, ist eine durchgängige Sichtbarmachung in der Oberfläche. Ein Nutzer, der einen geteilten Ordner betrachtet, kann nicht ohne Weiteres erkennen, ob der angezeigte Name der Originalname ist oder sein eigener Zielname. Ein dezenter Hinweis an dieser Stelle wäre eine kleine Änderung mit großer Wirkung. Bis dahin bleibt es Aufgabe der Administration, den Mechanismus zu erklären – und das ist, gemessen an den sonstigen Herausforderungen im Betrieb einer Collaboration-Plattform, eine dankbare Aufgabe. Wer ihn einmal verstanden hat, versteht auch, warum derselbe Ordner bei fünf Kollegen fünf verschiedene Namen trägt. Und warum das in Ordnung ist.

Kurz zusammengefasst

Ein Freigabeobjekt hat einen Originalnamen beim Eigentümer und je Empfänger einen eigenen Zielnamen. Beide dürfen sich unterscheiden.
Technisch steckt der Zielname im Feld file_target der Tabelle oc_share. Die Datei-ID bleibt über Umbenennungen hinweg stabil.
Benennt ein Empfänger um, ändert sich nur sein Mountpunkt. Beim Eigentümer passiert nichts.
Benennt der Eigentümer um, ziehen Empfänger ohne eigenen Zielnamen mit; individuelle Namen bleiben bestehen.
Öffentliche Links überleben jede Umbenennung, weil sie auf die Datei-ID zeigen.
Der Standardablageort für eingehende Freigaben lässt sich über share_folder steuern.
API und WebDAV erlauben automatisierte Umbenennungen; die Semantik ist versionsabhängig und gehört getestet.
Desktop-Clients behandeln Umbenennungen als Verschiebevorgang – Vorsicht bei reinen Groß-/Kleinschreibungsänderungen.
Gruppenordner und externe Speicher folgen eigenen Regeln; hier ist Umbenennen meist nicht vorgesehen.
Die wichtigste Maßnahme ist organisatorisch: klare Konventionen, klare Kommunikation, klare Dokumentation.

Warum derselbe Nextcloud Ordner bei jedem anders heißt