Freigaben in Nextcloud umbenennen: Ein Praxisbericht über ein scheinbar simples Thema

Alexander hatte alles vorbereitet. Die Ordnerstruktur für das neue Projekt stand, die Kolleginnen aus der Redaktion hatten ihre Freigaben, die externen Grafiker hatten ihre Links. Dann kam die E-Mail aus der Geschäftsleitung: „Können wir das Verzeichnis in ‚Projekt_Mercury‘ umbenennen?“ – Und plötzlich steht man vor einer Frage, die harmloser klingt, als sie ist: Was passiert mit all den Nextcloud-Freigaben, wenn sich der Name der Quelle ändert?

Die kurze Antwort lautet: weniger, als man hofft. Die längere Antwort führt in eine Ecke von Nextcloud, die manchen Administrator graue Haare wachsen lässt. Denn das Umbenennen einer geteilten Ressource ist in Owncloud/Nextcloud grundsätzlich kein technisches Problem – aber das, was auf den Bildschirmen der Empfänger passiert, folgt einer eigenen Logik, die nur der versteht, der sich mit der internen Funktionsweise von Shares beschäftigt hat.

Zwei Welten in einem Dateisystem

Wer Nextcloud als eine Art Wikipedia für Dateien nutzt, verkennt schnell die eigentliche Architektur. Auf der einen Seite gibt es die Dateien, die physisch im Benutzerkonto liegen. Auf der anderen Seite gibt es die Freigaben, die diese Dateien für andere sichtbar machen. Die Freigabe ist aber kein simpler Symlink, sondern ein eigener Datenbankeintrag, der eine Datei oder einen Ordner über eine ID referenziert. Diese Datei-ID bleibt stabil, solange die Datei existiert – auch wenn sie verschoben, in einen anderen Ordner gehoben oder umbenannt wird.

Das klingt zunächst einmal elegant. Wenn ich als Eigentümer also einen bereits geteilten Ordner umbenenne, bleibt die Verbindung zum Empfänger technisch erhalten. Der Empfänger sieht weiterhin eine Freigabe in seiner Ablage, die auf dieselbe Datei-ID verweist. Nur: Der Name, der beim Empfänger auftaucht, ist nicht unbedingt der Name, den ich als Eigentümer gerade vergeben habe. Das ist der Moment, in dem viele zum ersten Mal stutzen.

Das Gegenstück zum Dateinamen im Besitzerkonto ist der sogenannte Mountpoint. So heißt der Eintrag, der beim Empfänger im Dateisystem angelegt wird. Dieser Eintrag hat einen eigenen Namen, der unabhängig vom Quellpfad existiert. In der Datenbank steht dieser Name im Feld file_target der Tabelle oc_share. Wenn ich als Eigentümer den Ordner „Briefing“ in „Briefing_2025“ umbenenne, dann bleibt der Mountpoint des Empfängers unbeirrt bei „Briefing“ stehen.

Das ist kein Bug, sondern eine Design-Entscheidung. Sie schützt den Empfänger davor, dass sich seine eigenen Verknüpfungen, Sync-Ordner und Notizen schlagartig ändern. Aber sie führt zu einem Alltagsproblem: Informationen über Umbenennungen erreichen die Empfänger nicht. Die Freigabe lebt in ihrer eigenen Welt, und die Datei lebt woanders.

Die Quelle wechselt den Namen – der Empfänger merkt es nicht

Dieser Punkt ist der häufigste Auslöser für Verwirrung in Projekten. Ein Team arbeitet mit einem zentralen Ordner, alle haben die Freigabe darauf. Nun entscheidet das Team, den Ordnernamen zu präzisieren. Der Eigentümer führt die Umbenennung im Web-Interface durch – zwei Klicks, fertig. Doch wenn die Kollegen ihre Nextcloud-Ansicht aktualisieren, sehen sie weiterhin den alten Namen. Ihre lokalen Verzeichnisse, in die sie die Freigabe mit dem Desktop-Client synchronisiert haben, heißen weiterhin so wie vorher.

Beim Desktop-Client kommt noch ein zweiter Effekt hinzu: Der synchronisierte Ordner ist in der Regel mit einer lokalen Pfadangabe verknüpft. Ändern Sie als Eigentümer den Namen, passiert auf dem Rechner des Empfängers gar nichts. Der Client erkennt irgendwann, dass der Quellordner, den er über die Freigabe sieht, noch existiert – aber eben unter neuem Namen. Das Ergebnis sind zwei Ordner im lokalen Verzeichnis: der alte, der nicht mehr synchronisiert wird, und der neue, der allmählich befüllt wird. Wenn dann noch beide Namen ähnlich lauten, ist das Chaos perfekt.

Manchen mag das als kosmetisches Problem erscheinen. Bei einer sorgfältig gepflegten Ablagestruktur ist es jedoch ein erheblicher Eingriff. Einmal umbenannt, müssen alle Beteiligten ihre Lesezeichen, ihre Dokumentation, manchmal sogar ihre E-Mails anpassen. Die Freigabe selbst aber bleibt stumm.

Ein interessanter Aspekt ist dabei: Die öffentlichen Links überleben eine Umbenennung problemlos. Wer einen Link zu einer Datei oder einem Ordner gesetzt hat, kann die Ressource gefahrlos umbenennen, der Link bringt die Empfänger weiterhin ans Ziel. Das funktioniert, weil der öffentliche Link nicht an einen Pfad, sondern an eine Datei-ID gekoppelt ist. Bei Benutzerfreigaben dagegen sieht die Sache anders aus: Die Benutzerfreigabe zeigt auf den Mountpoint – und der verharrt auf dem alten Namen.

Darf der Empfänger selbst anpacken?

Kann der Empfänger den freigegebenen Ordner in seiner eigenen Nextcloud-Ansicht wenigstens selbst umbenennen? Das ist eine der am häufigsten gestellten Fragen in Nextcloud-Foren – und die Antwort ist ernüchternd. In der Weboberfläche gibt es für einen fremden freigegebenen Ordner, der als oberste Ebene einer Freigabe erscheint, in der Regel keinen Umbenennen-Button. Der Menüpunkt fehlt, obwohl der Empfänger über Bearbeiten- oder Löschrechte verfügen kann.

Technisch ließe sich der Mountpoint mit Bordmitteln verändern, aber die Entwickler haben diese Möglichkeit bisher nicht vorgesehen. Der Grund dafür liegt in der Komplexität der Berechtigungen. Wenn der Empfänger nur Leserechte besitzt, wäre eine Umbenennung ein Eingriff in die öffentliche Wahrnehmung eines Ordners, der ihm gar nicht gehört. Wenn er Schreibrechte hat, könnte man argumentieren, dass er auch den Namen ändern darf. Doch Nextcloud trennt streng zwischen den Rechten am Inhalt und den Rechten an der Ordnung.

Auch über WebDAV, also über den direkten Pfad /remote.php/dav/files/Benutzername/, lässt sich ein fremder freigegebener Ordner nicht auf Anhieb umbenennen. Ein MOVE auf einen solchen Mountpoint scheitert in den meisten Fällen, weil die Berechtigung am Mount-Punkt selbst nicht ausreicht. Das ist anders, wenn Sie eine Freigabe lediglich in einen eigenen Ordner kopieren. Dann haben Sie die Daten im eigenen Bestand und können damit tun, was Sie wollen – aber Sie arbeiten dann nicht mehr mit der Freigabe des Besitzers, sondern mit einer Kopie.

All das führt zu einer seltsamen Schieflage: Der Eigentümer kann den Quellordner umbenennen, ohne dass es beim Empfänger sichtbar wird. Der Empfänger kann den Namen seiner Freigabe nicht ändern, ohne die Verbindung zum Eigentümer zu kappen. Es ist, als hätten zwei Parteien das Recht, denselben Ordner zu sehen, aber niemand hat die Hoheit über das Etikett, das der jeweils andere sieht.

Öffentliche Links und der nette Schein

Ganz anders verhält es sich bei den öffentlichen Freigaben, also jenen Links, die Nextcloud als URL verschickt. Hier gibt es tatsächlich so etwas wie eine Umbenennung, nämlich den Namen des Links beziehungsweise das, was Nextcloud als „Link-Name“ bezeichnet. Sie können diesen Namen jederzeit ändern, ohne die URL anzufassen. Der Name taucht dann auf der öffentlichen Seite als Titel auf und dient Empfängern als Orientierung.

Wer eine öffentliche Freigabe über die Weboberfläche erstellt, findet in den Link-Einstellungen das Feld „Name“. Dieses Feld ist nicht mit dem Dateinamen identisch. Die Datei kann zum Beispiel „Vertrag_entwurf_v3_final_2025.pdf“ heißen, während der Link den Titel „Aktueller Vertragsentwurf“ trägt. Das ist eine bewusst eingebaute Abstraktionsschicht. Sie erlaubt es, Unbeteiligten eine saubere Bezeichnung zu präsentieren, ohne die unleserliche Dateibenennung im Backend zu ändern.

Für alle, die eine automatisierte Ablage pflegen, ist das eine der wichtigsten Stellschrauben überhaupt. Denn über die OCS-API, die Nextcloud für Freigaben bereitstellt, lässt sich dieses Label auch per Skript setzen. In der Praxis bedeutet das: Wer regelmäßig Berichte oder Exporte teilt, kann den Link stabil lassen und trotzdem jedes Mal den Titel anpassen. Das nächste Mal, wenn Sie einen Kunden-Link in einem CRM vermerken, brauchen Sie keine neue URL zu erzeugen, nur weil sich der Projektname geändert hat.

Freilich ist das keine echte Umbenennung der Freigabe im engeren Sinn. Wer nach „Nextcloud Share umbenennen“ sucht, meint meist etwas anderes: Er möchte, dass ein bereits verteilter Ordner im gesamten Firmenkosmos einen neuen Namen bekommt. Und genau das kann Nextcloud nicht in einem Rutsch. Es gibt keinen globalen Mechanismus, der eine Umbenennung der Quelle an alle Empfänger propagiert.

Workarounds, die den Alltag retten

Was also tun, wenn die Umbenennung eines geteilten Ordners ansteht? In der Projektpraxis hat sich ein mehrstufiges Vorgehen bewährt, das zwar etwas manuell ist, aber keine Datenverluste riskiert.

Der erste Weg ist der alte Ordner-Name wird nicht angefasst, sondern nur der Inhalt. Sie legen einen neuen Ordner mit dem Wunschnamen an, verschieben die Daten und teilen den neuen Ordner. Die alte Freigabe löschen Sie erst, wenn alle Empfänger bestätigt haben, dass sie die neue Freigabe sehen. Das ist nicht elegant, aber sauber. Alle Beteiligten haben dann eine frische Struktur, der Desktop-Client kann den neuen Ordner sauber aufbauen, und es bleibt keine verwaiste Synchronisationsreferenz zurück.

Der zweite Weg funktioniert, wenn der Empfänger die Daten ohnehin lokal weiterverarbeiten muss: Er kann den freigegebenen Ordner in sein persönliches Verzeichnis verschieben – vorausgesetzt, die Berechtigungen erlauben das. Dabei wird der Ordner aus der Freigabe gelöst und dem eigenen Konto zugeschlagen. Danach ist der Empfänger Eigentümer einer echten Kopie. Das ist oft die einzige Möglichkeit, wenn ein Mitarbeiter einen Projektordner dauerhaft in seiner eigenen Ablage führen will, ohne dass ihm die Freigabe jederzeit wieder entzogen werden kann.

Ein dritter, eher pragmatischer Ansatz ist die schlichte Kommunikation. Wenn Sie als Eigentümer einen Ordner umbenennen wollen, schreiben Sie den Empfängern vorher eine Nachricht. Weisen Sie darauf hin, dass der alte Ordnername in der Freigabe bestehen bleibt, aber der Inhalt gewechselt hat. Klingt simpel, erspart aber jede Menge Rückfragen. Vor allem in Teams, die nicht täglich mit Nextcloud arbeiten, ist dieser Hinweis Gold wert.

Für Administratoren sei noch erwähnt, dass eine Umbenennung der Quelle niemals dazu führen sollte, dass der fragliche Ordner über einen anderen Pfad verschoben wird, während ein Empfänger gerade Dateien synchronisiert. Nextcloud verträgt das zwar technisch, aber die Clients brauchen einen Moment, um die Verschiebung zu erkennen. Wer mag, kann diesen Vorgang in einem Wartungsfenster durchführen. In der Praxis reicht es, den betroffenen Nutzern kurz Bescheid zu geben.

Warum ein SQL-Update verführerisch ist

In Foren und Support-Threads taucht immer wieder derselbe Vorschlag auf: Ändert doch einfach den file_target des Shares in der Datenbank. Tatsächlich funktioniert das. Ein gezieltes UPDATE auf die Tabelle oc_share kann den Mountpoint des Empfängers schlagartig umbenennen. Die Zeile, in der der Share definiert ist, enthält auch den Pfad der Freigabe im Konto des Empfängers. Wenn Sie diesen Pfad ändern, erscheint beim nächsten Laden der Dateiliste der neue Name.

Doch wer sich auf dieses Abenteuer einlässt, sollte wissen, was er tut. Der Mountpoint ist nicht nur ein Anzeigename. Er wird auch von den Clients referenziert. Weicht der Datenbankwert von den lokalen Ordnernamen ab, versucht der Desktop-Client womöglich, eine neue Synchronisationsbeziehung aufzubauen, während die alte noch besteht. Das kann zu Duplikaten führen, die sich nur schwer wieder auflösen lassen. Dazu kommt: Freigaben können an mehrere Benutzer oder Gruppen gehen. Der file_target ist bei jedem Empfänger separat gespeichert. Ein einziges SQL-Update ändert also nur eine Zeile, nicht alle Empfänger.

Wer dennoch über diesen Weg nachdenkt, sollte unbedingt ein Backup der Datenbank anlegen und die betroffenen Benutzer davon abhalten, zum selben Zeitpunkt zu synchronisieren. Und: Die Änderung am file_target wirkt nur auf die Freigabe selbst. Der Quellordner, also die tatsächliche Datei, trägt weiterhin seinen bisherigen Namen. Sie verschieben mit dem SQL-Update also nicht die Datei, sondern nur das Schild, das dem Empfänger den Ordner ankündigt.

Es gibt leider kein offizielles occ-Kommando, das eine solche Umbenennung von Shares über die Kommandozeile erledigt. Das passende Werkzeug müsste eigentlich occ share:rename heißen, existiert aber nicht. Auch die Datei-Scans, die man nach einem SQL-Update anstoßen sollte, sind mit Vorsicht zu genießen: Ein occ files:scan gleicht den Dateibestand ab, nicht die Mountpoints der Freigaben.

Automatisierung über die OCS-API

Für alle, die regelmäßig Freigaben einrichten, ist die OCS-API von Nextcloud ohnehin das wichtigste Werkzeug. Über sie lassen sich Freigaben erstellen, Berechtigungen setzen und öffentliche Links verwalten. Was viele nicht wissen: Auch der Name von öffentlichen Freigaben ist über die API steuerbar. Der relevante Endpunkt lautet /ocs/v2.php/apps/files_sharing/api/v1/shares. Beim Anlegen einer Freigabe können Sie den Parameter name mitgeben; bei bestehenden Freigaben geht das mit einem PUT-Request.

In einem typischen Skript sieht das so aus: Sie rufen die Liste der Shares ab, suchen sich die Share-ID des entsprechenden Links und setzen den Parameter name neu. Das alles lässt sich in wenigen Zeilen Bash-Curl abbilden. Die URL der Freigabe bleibt unverändert, der Titel wechselt. Das ist eine der wenigen „renaming“-Fähigkeiten, die Nextcloud ohne Wenn und Aber unterstützt.

Aufpassen muss man bei der Nutzung der API bei Benutzerfreigaben. Dort gibt es zwar ebenfalls das Feld name, aber es hat eine andere Bedeutung. Es ist kein Anzeigename für den Empfänger, sondern der Name des ursprünglichen Elements. Der Parameter wird abhängig vom Share-Typ unterschiedlich interpretiert. Wer über die API eine Benutzerfreigabe umbenennen möchte, findet dafür keinen offiziellen Endpunkt. Die Dokumentation verweist auf die Berechtigungen, und die Endbenutzeroberfläche bietet, wie beschrieben, keine Funktion.

Wer dennoch eine systematisierte Umbenennung aller Freigaben eines Ordners benötigt, kommt an einem Zwischenschritt nicht vorbei: Freigabe löschen, Ordner umbenennen, Freigabe neu anlegen. Das mag umständlich wirken, ist aber aus Sicht der Systemarchitektur die einzig saubere Lösung. Bei dieser Gelegenheit lassen sich dann auch gleich die Berechtigungen neu justieren – was in vielen Teams ohnehin überfällig ist.

Groupfolders: Team-Freigaben anders gedacht

Ein Stück weit ausweichen kann man dem Problem, wenn man nicht mit Einzelfreigaben, sondern mit Gruppenordnern arbeitet. Nextclouds Groupfolders werden zentral vom Administrator angelegt und lassen sich in der Weboberfläche als eigene Abteilung im Dateibaum einbinden. Ein Gruppenordner verhält sich wie eine Mischung aus lokalem Ordner und Freigabe: Er gehört keinem einzelnen Nutzer, sondern einer Gruppe, und seine Ordnerstruktur ist für alle gleichermaßen verbindlich.

Wenn nun ein zentraler Teamordner umbenannt werden soll, geschieht das am Gruppenordner direkt. Alle Mitglieder der Gruppe sehen den neuen Namen sofort, weil es keinen individuellen Mountpoint gibt. Auch die Synchronisierung über die Desktop-Clients funktioniert in der Regel besser, weil Nextcloud Gruppenordner wie eigene Daten behandelt. Einzelne Nutzer können einen Gruppenordner allerdings nicht umbenennen, ohne entsprechende Verwaltungsrechte zu besitzen. Das ist in einer Organisation aber eher ein Vorzug als ein Manko.

Für Unternehmen, die Nextcloud als zentrale Ablage einsetzen, sind Groupfolders deshalb die deutlich robustere Alternative zur klassischen Benutzerfreigabe. Die Konfiguration erfolgt über die Administration, die Berechtigungen lassen sich granulär steuern, und das gefürchtete Problem der „hängen gebliebenen“ Freigabenamen tritt nicht auf. Leider werden Groupfolders in vielen Projekten erst entdeckt, nachdem die Wildwuchs-Freigaben schon überhandgenommen haben.

Föderation und die zweite Server-Reihe

Wer Nextcloud nicht nur innerhalb einer eigenen Installation betreibt, sondern mit anderen Instanzen über Federation verbindet, steht vor einer weiteren Besonderheit. Federated Shares sind Freigaben, die von einem Nextcloud-Server zu einem anderen geschickt werden. Die Prinzipien ähneln denen der internen Freigaben: Der Empfänger sieht einen Mountpoint, der nicht synchron mit der Quelle umbenannt wird. Auch hier gilt: Der Name beim Empfänger bleibt so, wie er bei der Freigabe angelegt wurde.

Erschwerend kommt hinzu, dass der sendende Server keine direkte Kontrolle über die Darstellung auf dem empfangenden Server hat. Eine Umbenennung der Quelle per SQL würde auf dem entfernten Server gar nichts bewirken, weil dort ein eigener Datenbankeintrag existiert. Will man bei Föderationen den Namen einer Freigabe also korrigieren, bleibt nur der Weg über den Administrator des entfernten Servers. Oder man hebt die Freigabe auf und setzt sie neu.

Diese Asymmetrie ist bei föderierten Arbeitsgruppen besonders lästig. Das lässt sich nur durch klare Absprachen zwischen den Instanzen abfedern. Es wäre wünschenswert, dass Nextcloud in einem künftigen Release eine Option mitliefert, um freigegebene Ressourcen zentral umzubenennen und die Änderung an die verbundenen Server zu propagieren. Bislang scheitert das nicht an der Technik, sondern an der Frage, wer das Recht dazu haben soll. Diese Diskussion ist in der Community durchaus lebhaft.

Was bleibt: Klartext statt Wundermittel

Wenn man sich all das vor Augen führt, wird eines deutlich: Nextcloud ist ein mächtiges System, aber die Pflege von Freigaben erfordert ein gewisses Verständnis für die inneren Abläufe. Das Umbenennen einer geteilten Ressource ist nur dann problemlos, wenn man die Erwartungen richtig steuert. Der Eigentümer kann seine Datei frei umbenennen – aber er muss davon ausgehen, dass die Namensschilder bei den Empfängern nicht mitwachsen. Die Empfänger wiederum können den Namen einer Freigabe nicht einfach an ihre Bedürfnisse anpassen, weil Nextcloud den Mountpoint nicht als benutzereigenes Objekt betrachtet.

Für Administratoren heißt das: Schult die Nutzer frühzeitig, dann bleiben viele Missverständnisse aus. Erklärt in euren Nextcloud-Richtlinien, wie ihr mit Umbenennungen umgeht, und erstellt am besten eine Handreichung, die genau beschreibt, was beim Umbenennen geteilter Ordner zu tun ist. Dazu gehört auch die Frage, ob öffentliche Links nach einer Umbenennung weiter genutzt werden können – sie können – und ob es sich empfiehlt, auf Groupfolders umzusteigen.

Die eingangs erwähnte Geschichte von Alexander endete übrigens mit einem Kompromiss: Der Ordner wurde umbenannt, die Freigaben blieben zunächst bestehen, und alle Beteiligten bekamen eine kurze E-Mail. In der Ablage sah man danach weiterhin den alten Ordnernamen, wer öffnete, fand die neuen Dateien. Dass die Geschäftsleitung das als unprofessionell empfand, kann man nachvollziehen. Aber Nextcloud ist kein Werkzeug, das Namen um jeden Preis vereinheitlicht. Es ist ein Werkzeug, das Sichtbarkeiten organisiert – und manchmal muss man die Ordnung eben selbst herstellen.

So bleibt am Ende der Rat, den man in dieser Form auch in der offiziellen Dokumentation lesen kann: Prüft vor jeder Umbenennung, welche Freigaben an dem Ordner hängen. Macht euch klar, dass die Umbenennung keinen Einfluss auf die bereits vergebenen Freigaben hat. Und plant bei größeren Strukturen einen sauberen Schnitt: alte Freigabe beenden, neuen Ordner anlegen, neu teilen. Das ist nicht spektakulär, aber es funktioniert – und zwar auf allen Clients und allen Servern gleichermaßen.

Ein letzter Tipp noch, weil er oft vergessen wird: Die Dateiaktivitäten von Nextcloud zeigen sehr genau an, wer wann welche Datei umbenannt hat. Wenn Sie also einmal unsicher sind, ob eine Umbenennung eines geteilten Ordners schon stattgefunden hat, schauen Sie in die Aktivitäten. Manchmal findet man dort die Erklärung dafür, warum ein Empfänger plötzlich von einem „verschwundenen“ Ordner spricht, obwohl im eigenen Konto alles an seinem Platz liegt. Auch das wiederspiegelt die zweigeteilte Welt der Freigaben: Was für die einen eine simple Verschiebung ist, kann für die anderen wie eine radikale Löschung wirken.