Dateien

Dateimanager für Freigaben, Datasets und /appdata: Hochladen, Herunterladen, Umbenennen, Verschieben, Kopieren, Löschen, Besitzer und Rechte.

Die Seite Dateien arbeitet direkt auf dem Dateisystem des NAS, als root. Sie ist für Verwaltungsaufgaben gedacht (Ordner anlegen, Rechte reparieren, eine Datei schnell hoch- oder herunterladen); für die tägliche Arbeit mit vielen Dateien sind die SMB- und NFS-Freigaben besser geeignet.

Ablageorte

Oben links wählst du den Ablageort. Angeboten werden nur:

Art	Herkunft
Apps	/appdata (die App-Verzeichnisse)
Freigabe	der Pfad jeder SMB/NFS-Freigabe
Dataset	jedes eingehängte ZFS-Dataset, dessen Pfad nicht schon eine Freigabe ist
Netzlaufwerk	jedes eingehängte Netzlaufwerk unter /mnt/remotes, dessen Pfad nicht schon eine Freigabe ist

Systempfade (/, /etc, /usr, /var, /root, /boot, /proc, /sys, /dev, /run, /tmp und weitere) sind nie Ablageorte. Das Verzeichnis /appdata/bunkerbox (Bunkerbox selbst mit Sitzungen und Zugangsdaten) wird ausgeblendet und ist auch über einen Pfad nicht erreichbar. Netzlaufwerke im Zustand „wartet“ (Automount noch nicht ausgelöst) werden nicht angeboten, damit das Öffnen nicht hängt.

Die Adresse der Seite enthält Ablageort und Ordner (/files?root=share:media&path=filme) und lässt sich als Lesezeichen speichern.

Sicherheit

• Jeder Pfad wird als Ablageort plus relativer Pfad übergeben; jede Komponente muss ein gültiger Name sein (kein /, kein . oder .., keine Steuerzeichen).
• Bunkerbox geht vom Ablageort aus jede Komponente einzeln mit lstat durch: Jeder Ordner auf dem Weg muss ein echter Ordner sein, symbolische Links werden nie verfolgt, auch nicht im letzten Teil (Dateien werden mit O_NOFOLLOW geöffnet). Zusätzlich muss der echte Pfad (realpath) des übergeordneten Ordners dem angezeigten Pfad entsprechen. So kann weder .. noch ein von einem Freigabe-Benutzer angelegter Link aus dem Ablageort herausführen.
• Symbolische Links werden angezeigt, lassen sich aber weder öffnen noch herunterladen; beim Kopieren werden sie als Link kopiert.
• Downloads werden immer als Anhang mit Content-Type: application/octet-stream und einer Sandbox-CSP ausgeliefert, damit hochgeladene HTML-Dateien nie im Kontext der Oberfläche laufen.
• Hochladen läuft als gestreamte Anfrage an /api/files/upload. Diese Route prüft Anmeldung, zweite Stufe und Herkunft (Origin) selbst, weil der Zugriffsschutz-Proxy von Next.js große Anfragen im Speicher puffern und nach 10 MB abschneiden würde.
• Alle ändernden Aktionen stehen im Audit-Log (files.*).

Ansicht

Die Tabelle zeigt Name, Größe, Änderungszeit, Besitzer:Gruppe und Rechte (rwxr-x---, oktal als Tooltip). Spalten lassen sich durch Klick auf die Überschrift sortieren, Ordner stehen immer oben; das Filterfeld durchsucht den aktuellen Ordner. Mehr als 5000 Einträge in einem Ordner werden abgeschnitten. Auf schmalen Bildschirmen werden nur Name und Größe angezeigt. Die Ansicht aktualisiert sich alle 15 s.

Aktionen

Aktion	Verhalten
Neuer Ordner	übernimmt Besitzer, Gruppe und Rechte (inkl. Setgid) des übergeordneten Ordners
Hochladen	Dateien auswählen oder in die Tabelle ziehen; eine Datei nach der anderen mit Fortschrittsanzeige, abbrechbar. Die Datei wird zuerst als versteckte Teildatei geschrieben und erst nach vollständiger Übertragung unter ihrem Namen abgelegt; abgebrochene Übertragungen hinterlassen nichts. Neue Dateien übernehmen Besitzer und Gruppe des Ordners und dessen Lese-/Schreibrechte (ohne Ausführen). Gibt es den Namen schon, fragt die Liste nach Ersetzen oder Überspringen. Ordner lassen sich nicht hochladen. Vorab prüft Bunkerbox den freien Platz; auf dem Systemdatenträger bleiben mindestens 1 GiB bzw. 5 % frei. Kommen 5 Minuten lang keine Daten an, wird der Upload abgebrochen
Herunterladen	Dateien direkt (Klick auf den Namen), Ordner als ZIP-Datei, die beim Herunterladen erzeugt wird (unkomprimiert, ZIP64 für große Dateien; symbolische Links und Sonderdateien fehlen im Archiv)
Umbenennen	im selben Ordner; ein vorhandener Name wird nicht überschrieben
Verschieben, Kopieren	in einen beliebigen Ordner eines beliebigen Ablageorts. Vorhandene Dateien gleichen Namens werden nur mit Ersetzen überschrieben, Ordner nie. Kopien behalten Besitzer, Gruppe, Rechte und Änderungszeit (ACLs und erweiterte Attribute werden nicht mitkopiert); in einen anderen Ablageort kopiert, gehören sie dem Besitzer und der Gruppe des Zielordners. Setuid und Setgid von Dateien werden nie mitkopiert. Verschieben innerhalb eines Datasets ist sofort fertig; zwischen Datasets wird kopiert und danach das Original gelöscht
Löschen	Dateien nach Bestätigung, Ordner nur einzeln und nach Eingabe des Ordnernamens. Enthält ein Ordner ein anderes eingehängtes Dateisystem (z. B. ein Dataset), wird das Löschen vorher verweigert
Besitzer	Benutzer und Gruppe aus /etc/passwd und /etc/group, für Ordner optional für den ganzen Inhalt
Rechte	Lesen/Schreiben/Ausführen für Besitzer, Gruppe und Andere sowie Setuid, Setgid und Sticky, auch als Oktalwert. Rekursiv erhalten Ordner genau diese Rechte; Dateien bekommen Ausführen nur, wenn sie schon ausführbar waren (wie chmod X), Setuid/Setgid werden bei Dateien nicht gesetzt

Kopieren, Verschieben, Löschen und rekursive Änderungen laufen im Hintergrund und erscheinen mit Fortschritt unter Vorgänge; solange sie laufen (und solange hochgeladen wird), verweigert Bunkerbox ein Update. Rekursive Änderungen und das Löschen gehen nie in andere eingehängte Dateisysteme hinein. Alle Vorgänge arbeiten über geöffnete Ordner (/proc/self/fd): Ersetzt jemand per SMB oder NFS währenddessen einen Ordner durch einen symbolischen Link, wirkt das nicht nach außerhalb des Ablageorts.

Die Rechte einer Freigabe (ACLs) setzt der Dateimanager nicht. Sind sie durcheinandergeraten, wende sie unter Freigaben erneut an.

Ein Ablageort selbst (z. B. der Ordner einer Freigabe) lässt sich nicht umbenennen, verschieben oder löschen.

API

Methode	Pfad	Beschreibung
GET	/api/files/roots	FileRoot[]
GET	/api/files/list?root=&path=	DirectoryListing
GET	/api/files/stat?root=&path=	FileEntry
GET	/api/files/principals	Benutzer und Gruppen für den Besitzer-Dialog
GET	/api/files/download?root=&path=	Datei oder ZIP-Stream
POST	/api/files/upload?root=&path=&name=&overwrite=1	roher Dateiinhalt als Body, Header x-bunkerbox-upload: 1 -> 201 FileEntry
POST	/api/files/mkdir, /api/files/rename	CreateFolderRequest, RenameRequest
POST	/api/files/move, /api/files/copy	TransferRequest -> 202 FileOperation
POST	/api/files/delete	DeleteFilesRequest -> 202 FileOperation
POST	/api/files/chown, /api/files/chmod	ChangeOwnerRequest, ChangeModeRequest -> 202 FileOperation
GET	/api/files/operations, /api/files/operations/[id]	laufende und letzte Vorgänge (die letzten 50, im Speicher)

Testmodus

Mit BUNKERBOX_MOCK=1 liegen die simulierten Pfade (/tank/media, /tank/documents, /appdata, …) in einem Spielordner data/mock-files/, der beim ersten Aufruf mit Beispieldateien gefüllt wird. Alle Aktionen arbeiten dort wirklich, Besitzer und Rechte werden nur simuliert (das funktioniert auch unter Windows). Zum Zurücksetzen den Ordner löschen.