Synology: Einen Mount sauber entfernen

Auf einer Synology kann ein Ordner in File Station wie ein eingebundener Datenträger oder eine Verbindung aussehen, obwohl er technisch vielleicht gar kein aktiver Mount mehr ist. Genau dieses Problem war im ursprünglichen Verlauf entscheidend: Unter einem Namen wie SYNO218 waren Inhalte sichtbar, aber umount meldete „not mounted“, während rmdir den Ordner wegen vorhandener Dateien nicht löschen wollte.

Die wichtigste Regel lautet deshalb: Nicht zuerst löschen, sondern zuerst feststellen, was der Pfad tatsächlich ist. Ein echter CIFS-/NFS-Mount, eine File-Station-Remote-Verbindung und ein normaler lokaler Ordner sind drei verschiedene Dinge und müssen unterschiedlich behandelt werden.

1. Wenn der Ordner über File Station eingebunden wurde

Synology kann Remote-Ordner von anderen NAS-Geräten oder Servern direkt in File Station bereitstellen. Aktuell unterstützt File Station dafür unter anderem CIFS/SMB und NFS.

Wenn die Verbindung dort erstellt wurde, solltest du sie auch dort zuerst entfernen:

  1. File Station öffnen.
  2. Den betreffenden Remote-Ordner markieren.
  3. Extras → Trennen beziehungsweise Unmount wählen.

Alternativ lässt sich ein Remote-Ordner laut Synology direkt per Rechtsklick trennen.

2. Mount-Liste in DSM prüfen

In aktuellen DSM-Versionen gibt es in File Station unter Extras → Mount-Liste eine Übersicht über virtuelle Laufwerke und Remote-Ordner. Dort lässt sich erkennen, welche File-Station-Mounts DSM tatsächlich verwaltet.

Wenn dein fraglicher Ordner dort auftaucht, ist der GUI-Weg eindeutig: Verbindung auswählen und sauber trennen.

3. Remote-Verbindung ist nicht dasselbe wie Remote-Ordner-Mount

File Station kennt zusätzlich Remote-Verbindungen zu FTP, SFTP, WebDAV oder Cloud-Diensten. Diese erscheinen ebenfalls in der linken Navigation, werden aber anders verwaltet.

Für solche Profile gibt es unter Extras → Remote-Verbindung → Verbindungsliste eine eigene Verwaltung.

Wenn die eine Liste leer ist, bedeutet das also nicht automatisch, dass überhaupt keine externe Einbindung vorhanden ist. Prüfe Mount-Liste und Remote-Verbindung getrennt.

4. Warum der Name /mnt/SYNO218 allein noch nichts beweist

Im ursprünglichen Gespräch wurde zu schnell angenommen: „Wenn es unter /mnt liegt, muss es ein aktiver Mount sein.“ Das ist nicht zuverlässig. Ein Verzeichnis kann schlicht /mnt/SYNO218 heißen, ohne dass dort aktuell etwas eingehängt ist.

Entscheidend ist nicht der Name, sondern die Mount-Tabelle des Linux-Systems.

5. Per SSH prüfen, ob es wirklich gemountet ist

Aktiviere bei Bedarf in DSM unter Systemsteuerung → Terminal & SNMP → Terminal den SSH-Dienst. Für eine verschlüsselte Verbindung solltest du SSH statt Telnet verwenden.

Dann verbindest du dich beispielsweise von Windows Terminal oder PowerShell:

ssh adminbenutzer@192.168.1.100

Danach kannst du die aktiven Mounts durchsuchen:

mount | grep SYNO218

Oder nach dem konkreten Zielpfad:

mount | grep '/mnt/SYNO218'

6. Zusätzliche Prüfung mit df

Auch df kann zeigen, welche Dateisysteme tatsächlich eingehängt sind:

df -h

Wenn der fragliche Zielpfad weder in mount noch in einer passenden df-Ausgabe auftaucht, ist er sehr wahrscheinlich kein aktiver klassischer Mountpunkt.

7. findmnt nur verwenden, wenn vorhanden

Auf vielen Linux-Systemen ist findmnt sehr praktisch:

findmnt /mnt/SYNO218

DSM basiert jedoch auf einer angepassten Linux-Umgebung; nicht jedes bekannte Linux-Werkzeug ist auf jedem Synology-Modell beziehungsweise jeder DSM-Version vorhanden. Wenn findmnt fehlt, reichen mount und df für die Grundprüfung.

8. Was eine echte Mount-Ausgabe verrät

Bei einem SMB/CIFS-Mount könnte die Ausgabe sinngemäß so aussehen:

//192.168.1.218/share on /volume1/remote/SYNO218 type cifs (...)

Bei NFS eher:

192.168.1.218:/volume1/share on /volume1/remote/SYNO218 type nfs (...)

Damit kennst du Quelle, Ziel und Protokoll.

9. Einen echten Mount sauber aushängen

Wenn der Pfad tatsächlich in der Mount-Tabelle steht, kannst du ihn per SSH aushängen:

sudo umount /volume1/remote/SYNO218

Verwende exakt den Zielpfad aus der Mount-Ausgabe.

Bei einem von File Station verwalteten Mount ist die GUI trotzdem vorzuziehen, weil DSM dabei auch seine eigene Verbindungsverwaltung berücksichtigt.

10. „not mounted“ ist eine wichtige Information

Wenn du:

sudo umount /mnt/SYNO218

ausführst und die Antwort sinngemäß „not mounted“ lautet, solltest du nicht mit stärkeren Force-Optionen weiterprobieren. Das System sagt dir gerade, dass dieser Pfad in der Mount-Tabelle nicht als aktiver Mountpunkt geführt wird.

Dann ist die nächste Frage: Was sind die Dateien, die in diesem Ordner liegen?

11. Warum rmdir „Directory not empty“ meldet

rmdir löscht ausschließlich leere Verzeichnisse. Die Fehlermeldung „Directory not empty“ ist deshalb ein Schutzmechanismus und kein Problem, das man umgehen muss.

Sie bedeutet: In diesem Verzeichnis liegen echte sichtbare Einträge. Bevor irgendetwas gelöscht wird, solltest du sie auflisten:

ls -la /mnt/SYNO218

Wenn dort Daten erscheinen, müssen Herkunft und Bedeutung geklärt werden.

12. Nicht einfach rm -rf verwenden

Gerade in diesem Szenario wäre ein blindes:

rm -rf /mnt/SYNO218

eine gefährliche Empfehlung. Wenn der Ordner lokale Dateien enthält, würden sie tatsächlich gelöscht. Wenn das Verzeichnis doch Teil einer unerwarteten Einbindung ist, könnten sogar entfernte Daten betroffen sein.

Lösche nichts, bevor du weißt, was du siehst.

13. Der entscheidende Linux-Effekt: Ein Mount verdeckt vorhandene Dateien

Warum verlangt Synology beim Einrichten eines Remote-Ordners ausdrücklich einen leeren Zielordner? Weil Linux beim Mounten die darunterliegenden lokalen Dateien nicht zusammenführt.

Wenn in einem Verzeichnis bereits lokale Dateien liegen und du ein anderes Dateisystem darauf mountest, werden diese lokalen Dateien während des Mounts verdeckt. Sie sind nicht gelöscht, aber vorübergehend nicht sichtbar.

Nach dem Aushängen erscheinen sie wieder.

14. Deshalb verlangt File Station ein leeres Mount-Ziel

Synology dokumentiert für CIFS- und NFS-Remote-Ordner ausdrücklich, dass als Ziel ein leerer Ordner gewählt oder erstellt werden soll. Das verhindert genau diese Verwechslung zwischen lokalen Daten und dem eingebundenen Remote-Inhalt.

15. Kann man technisch auf einen nicht leeren Ordner mounten?

Unter normalem Linux kann ein Mount technisch auf einem nicht leeren Verzeichnis möglich sein. Das ist aber für die Datenverwaltung riskant, weil vorhandene Dateien dadurch unsichtbar werden, solange der Mount aktiv ist.

File Station verhindert das sinnvollerweise und fordert einen leeren Zielordner.

16. Wenn File Station Dateien zeigt, SSH aber nicht

Im ursprünglichen Verlauf war genau diese Diskrepanz verwirrend. Dafür kommen mehrere Ursachen infrage:

  • Du vergleichst zwei unterschiedliche Pfade.
  • File Station zeigt einen virtuellen/remote eingebundenen Ort und nicht exakt /mnt/SYNO218.
  • der sichtbare Name ist nur ein Profilname.
  • die tatsächliche Einbindung liegt unter einem /volumeX/...-Pfad.

Öffne in File Station die Eigenschaften des Ordners und prüfe dessen tatsächlichen Ort, statt den angezeigten Namen als Linux-Pfad zu interpretieren.

17. Synology mountet Remote-Ordner nicht zwingend unter /mnt

Ein weiterer wichtiger Punkt: File-Station-Remote-Ordner werden laut Synology an Unterordnern von freigegebenen Ordnern eingehängt. Ein Ziel kann also beispielsweise unter /volume1/... liegen.

Der sichtbare Name „SYNO218“ sagt deshalb nicht automatisch, dass der Pfad /mnt/SYNO218 sein muss.

18. Automatisches Wiedereinhängen prüfen

Synology bietet beim Erstellen eines Remote-Mounts die Option, ihn beim Systemstart automatisch wieder einzuhängen. Wenn ein Mount nach einem Neustart zurückkommt, prüfe:

  • File-Station-Mount-Einstellungen,
  • Aufgabenplaner,
  • eigene Startskripte,
  • gegebenenfalls manuelle Systemkonfigurationen.

Ein einmaliges umount löst nicht die Ursache, wenn ein Skript die Verbindung später erneut herstellt.

19. Aufgabenplaner durchsuchen

Unter Systemsteuerung → Aufgabenplaner können benutzerdefinierte Skripte existieren. Suche dort nach Begriffen wie:

mount
cifs
nfs
SYNO218

Wenn ein Skript den Mount erzeugt, solltest du zuerst verstehen, wofür es eingerichtet wurde, bevor du es deaktivierst.

20. Hyper Backup und andere Pakete nicht vorschnell verantwortlich machen

Backup- oder Synchronisationspakete können selbstverständlich Netzwerkzugriffe erzeugen. Trotzdem sollte man nicht aus dem Namen eines Ordners ableiten, dass Hyper Backup oder ein bestimmtes Paket den Mount erzeugt hat.

Die belastbare Reihenfolge lautet: Mount-Tabelle prüfen, File-Station-Verwaltung prüfen, Aufgabenplaner prüfen und erst dann einzelne Pakete untersuchen.

21. Was tun bei „device is busy“?

Wenn ein echter Mount vorhanden ist, umount aber meldet, dass das Ziel belegt ist, greift noch ein Prozess darauf zu. Das kann File Station, ein Backup, ein Medienserver, ein Container oder eine Shell sein, deren aktuelles Arbeitsverzeichnis im Mount liegt.

Bevor du Force- oder Lazy-Unmount einsetzt, solltest du die zugreifenden Prozesse ermitteln beziehungsweise den zugehörigen Dienst sauber stoppen.

22. Lazy Unmount nicht als Standardlösung

umount -l kann in speziellen Situationen hilfreich sein, ist aber nicht der erste Befehl, den man bei jeder unklaren Einbindung verwenden sollte. Besonders bei Netzwerkdateisystemen können noch offene Dateizugriffe existieren.

Sauberer: Ursache identifizieren und regulär trennen.

23. SSH nach der Diagnose wieder deaktivieren?

Wenn du SSH sonst nicht benötigst, kannst du den Dienst nach Abschluss der Wartung wieder deaktivieren. Das reduziert unnötig offene Administrationsdienste.

Wenn SSH dauerhaft gebraucht wird, sollten starke Zugangsdaten beziehungsweise Schlüssel und eine sinnvolle Netzwerksicherheitskonfiguration verwendet werden.

24. Telnet würde ich nicht verwenden

DSM kann je nach Version auch Telnet anbieten. Für administrative Shell-Zugriffe ist SSH die bessere Wahl, weil die Verbindung verschlüsselt ist. Es gibt keinen sinnvollen Grund, für diese Diagnose bewusst auf das unverschlüsselte Telnet auszuweichen.

25. Sichere Diagnose-Reihenfolge

  1. In File Station prüfen, ob der Ordner als Remote-Mount erkennbar ist.
  2. Extras → Mount-Liste kontrollieren.
  3. zusätzlich Remote-Verbindung → Verbindungsliste prüfen.
  4. Eigenschaften des sichtbaren Ordners öffnen und echten Pfad feststellen.
  5. SSH aktivieren.
  6. mit mount und df -h nach dem Pfad suchen.
  7. Nur bei echtem Mount umount verwenden.
  8. Bei „not mounted“ den Ordnerinhalt untersuchen statt zu erzwingen.
  9. Lokale Dateien sichern/verstehen.
  10. erst einen wirklich leeren, nicht mehr benötigten Ordner mit rmdir entfernen.

26. Beispiel: SYNO218 ist kein aktiver Mount

Angenommen:

mount | grep SYNO218

liefert keine Ausgabe und:

sudo umount /mnt/SYNO218

meldet „not mounted“. Gleichzeitig:

ls -la /mnt/SYNO218

zeigt Dateien.

Dann solltest du diesen Ordner zunächst wie einen normalen lokalen Ordner mit Daten behandeln – nicht wie einen aktiven Mountpunkt.

27. Beispiel: echter CIFS-Mount

Wenn dagegen mount zeigt:

//192.168.1.218/share on /volume1/remote/SYNO218 type cifs

ist die Lage klar. Dann wird:

/volume1/remote/SYNO218

als Ziel ausgehängt – vorzugsweise über File Station, wenn DSM den Mount dort verwaltet.

Fazit

Beim Entfernen eines Synology-Mounts ist die Diagnose wichtiger als der Löschbefehl. Ein Ordnername in File Station oder unter /mnt beweist noch keinen aktiven Mount. Prüfe zuerst File-Station-Mount-Liste und Linux-Mount-Tabelle. Meldet umount „not mounted“ und enthält das Verzeichnis Dateien, darf man nicht einfach mit rm -rf weitermachen. Synology verlangt aus gutem Grund leere Zielordner: Ein Mount verdeckt vorhandene lokale Dateien, statt sie mit dem Remote-Inhalt zu verschmelzen.

Aktuell geprüft

Die Hinweise zu CIFS-/NFS-Remote-Ordnern, leeren Zielordnern, Mount-Liste, Trennen in File Station und SSH wurden mit der aktuellen Synology-DSM-Dokumentation abgeglichen.