Thomas/Homelab--Bratonein-Kontrollzentrum--Tutorial

Files

Thomas Dannenberg 4cb25b12c7 Kapitel 12/Free Rohtext.md hinzugefügt

2025-10-16 10:53:54 +00:00

32 KiB

Raw Permalink Blame History

Kapitel 12 – Asset-LXC

Einleitung

Der Asset-LXC ist ein zentraler Bestandteil des UCC und dient als dauerhafte Ablage für statische Dateien, die von verschiedenen Diensten gemeinsam genutzt werden.
Er ermöglicht die klare Trennung zwischen produktiven Anwendungen und den zugrunde liegenden Mediendateien, wodurch Systeme wie OBS, n8n, Nextcloud oder Webseiten effizienter und stabiler arbeiten können.

Im Gegensatz zu Nextcloud, das für Zusammenarbeit, Synchronisation und Benutzerfreigaben gedacht ist, konzentriert sich der Asset-LXC ausschließlich auf die Bereitstellung und Verwaltung von Dateien.
Er ist schlank, schnell und lokal vollständig unter deiner Kontrolle – unabhängig von externen Anbietern oder Cloud-Diensten.

Kern des Systems ist Filebrowser, eine leichtgewichtige Weboberfläche, über die du Dateien direkt im Browser hochladen, umbenennen, verschieben oder löschen kannst.
Damit steht ein eigenständiger Medien-Manager zur Verfügung, der einfach zu bedienen ist, keine aufwendige Datenbank benötigt und sich nahtlos in die bestehende UCC-Struktur einfügt.

Note

Filebrowser wird vollständig eingerichtet und ist nach Abschluss der Konfiguration direkt einsatzbereit.
Erweiterungen wie Netzlaufwerks-Einbindung unter Windows oder zusätzliche Automatisierungen bauen später auf diesem System auf, nutzen aber dieselbe Basis.

Ziel dieses Kapitels ist der Aufbau eines stabilen und sicheren Containers, der alle statischen Inhalte zentral verwaltet, klar strukturiert und langfristig als feste Infrastruktur-Komponente im UCC bestehen bleibt.

Voraussetzungen & Ressourcen

Bevor du mit der Einrichtung des Asset-LXC beginnst, überprüfe, ob dein System vollständig vorbereitet ist.
Die folgenden Punkte legen fest, welche Ressourcen und Bedingungen zwingend erfüllt sein müssen, damit der Container fehlerfrei betrieben werden kann.

Container-Ressourcen

CPU: 2 vCPUs
Zwei virtuelle Kerne sind die empfohlene Mindestgröße.
Filebrowser und Nginx profitieren von getrennten Threads für Uploads und gleichzeitige Webzugriffe.
RAM: 2 GB
Diese Menge stellt sicher, dass Uploads, Dateiverwaltung und Nginx-Dienste stabil laufen.
Bei geringeren Werten kann es unter Last zu Verzögerungen kommen.
Speicherplatz: 20 GB
Reicht für System, Logdateien, temporäre Uploads und kleinere Medienbestände.
Wenn du größere Mengen an Medien ablegen willst, sollte der Speicher direkt beim Erstellen des Containers erweitert oder ein zusätzliches Volume eingebunden werden.
Betriebssystem: Debian 12 (Bookworm)
Debian ist für den Asset-LXC optimal geeignet.
Es ist stabil, ressourcenschonend und erfordert keine zusätzliche Konfiguration für Nginx oder Filebrowser.
Alle Befehle und Pfade in diesem Kapitel beziehen sich auf Debian 12.
Netzwerk: statische IP-Adresse oder DHCP-Reservierung
Der Container muss dauerhaft unter derselben Adresse erreichbar sein,
da die spätere Proxy-Einbindung über eine feste Ziel-IP erfolgt.

Tip

Weise die IP-Adresse direkt bei der Containereinrichtung zu.
Eine nachträgliche Änderung würde sämtliche Proxy- und DNS-Einträge betreffen.

Technische Voraussetzungen

Proxmox VE ist installiert und funktionsfähig.
Der Container wird direkt über die Proxmox-Oberfläche erstellt und verwaltet.
Nginx Proxy Manager (NPM) ist eingerichtet.
Er wird benötigt, um die Weboberfläche von Filebrowser über HTTPS bereitzustellen.
DNS- oder DynDNS-Eintrag ist vorhanden.
Eine Subdomain wie assets.deinedomain.tld ist vorbereitet und im DNS eingetragen.
SSH-Zugriff auf den Container ist möglich.
Entweder über die Proxmox-Konsole oder per Terminal (z. B. ssh root@10.0.0.12).
Grundstruktur des UCC ist aktiv.
Proxmox, Nginx Proxy Manager und Netzwerkverbindungen laufen stabil,
damit der Container nach Fertigstellung sofort in das System eingebunden werden kann.

Important

Der Asset-LXC ist ein eigenständiger, dauerhaft aktiver Dienst.
Stelle sicher, dass er auf einem Host mit stabiler Netzwerkverbindung liegt und nicht mit anderen produktiven Containern gemeinsam auf einem kritischen Volume betrieben wird.

Schritt-für-Schritt-Anleitung

In diesem Abschnitt richtest du den Asset-LXC vollständig ein.
Alle Befehle sind direkt übernehmbar und so gewählt, dass sie ohne Anpassung ausgeführt werden können.
Am Ende dieses Abschnitts steht ein voll funktionsfähiger Container mit Nginx und Filebrowser, erreichbar über HTTPS.

Schritt 1 – System aktualisieren

Starte den Container über die Proxmox-Oberfläche und öffne anschließend die Konsole oder verbinde dich per SSH.
Bringe das System auf den aktuellen Stand:

apt update && apt upgrade -y
reboot

Nach dem Neustart erneut einloggen.

Note

Auch bei frisch erstellten Containern ist ein Systemupdate erforderlich.
Veraltete Paketquellen führen später zu Problemen bei der Installation von Nginx oder Filebrowser.

Schritt 2 – Grundverzeichnisse anlegen

Lege die Verzeichnisstruktur an, in der später alle Medien abgelegt werden.
Diese Struktur wird sowohl vom Webserver als auch von Filebrowser genutzt:

mkdir -p /srv/assets/{overlays,videos,sounds,projects,_meta}

Anschließend die Besitzerrechte für das System korrekt setzen:

chown -R www-data:www-data /srv/assets
chmod -R 755 /srv/assets

Tip

Lege die Verzeichnisstruktur zu Beginn konsequent an.
Einheitliche Pfade erleichtern dir später den Umgang mit Nginx, SMB und automatisierten Backups.

Schritt 3 – Nginx installieren

Installiere Nginx als Webserver.
Er wird benötigt, um die Dateien aus /srv/assets später per HTTPS auszuliefern.

apt install nginx -y

Nach Abschluss der Installation den Dienst prüfen:

systemctl status nginx

Wenn der Status active (running) angezeigt wird, läuft Nginx korrekt.

Note

Nginx dient in diesem Container ausschließlich der Dateiauslieferung und wird später über den Proxy Manager abgesichert.
Er übernimmt keine komplexen Webdienste.

Schritt 4 – Filebrowser installieren

Filebrowser wird direkt aus dem offiziellen Repository installiert.
Er benötigt keine zusätzlichen Abhängigkeiten und läuft als eigenständiger Dienst innerhalb des Containers.

curl -fsSL https://raw.githubusercontent.com/filebrowser/get/master/get.sh | bash

Nach erfolgreicher Installation kann der Dienst mit folgendem Befehl gestartet werden:

filebrowser -r /srv/assets -p 8080 &

Damit wird Filebrowser gestartet, nutzt /srv/assets als Arbeitsverzeichnis und ist über Port 8080 erreichbar.

Note

Der Befehl startet Filebrowser im Vordergrund.
Im nächsten Schritt wird er als dauerhafter Systemdienst eingerichtet, damit er automatisch startet.

Schritt 5 – Filebrowser als Dienst einrichten

Damit Filebrowser nach einem Neustart automatisch gestartet wird, muss ein Systemdienst erstellt werden.

nano /etc/systemd/system/filebrowser.service

Füge den folgenden Inhalt ein:

[Unit]
Description=Filebrowser Service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/filebrowser -r /srv/assets -p 8080
Restart=on-failure
User=root

[Install]
WantedBy=multi-user.target

Datei speichern (Strg + O, Enter, Strg + X) und den Dienst aktivieren:

systemctl daemon-reload
systemctl enable filebrowser
systemctl start filebrowser

Den Status prüfen:

systemctl status filebrowser

Wenn dort active (running) angezeigt wird, ist der Dienst aktiv und funktionsfähig.

Tip

Filebrowser läuft jetzt dauerhaft im Hintergrund und startet automatisch bei jedem Container-Neustart.
Alle Benutzer- und Dateiänderungen bleiben erhalten.

Schritt 6 – Zugriff im Browser testen

Öffne einen Browser und rufe die IP-Adresse des Containers mit Port 8080 auf, z. B.:

http://10.0.0.12:8080

Wenn alles korrekt eingerichtet wurde, erscheint die Anmeldeseite von Filebrowser.
Standardmäßig ist der Benutzername admin und das Passwort admin.

Melde dich an und ändere das Passwort unmittelbar nach dem ersten Login:

Oben rechts auf Benutzername → Einstellungen klicken.
Neues Passwort setzen und speichern.

Important

Das Standardpasswort ist öffentlich bekannt.
Ändere es sofort nach dem ersten Login, bevor der Container über den Proxy Manager nach außen erreichbar ist.

Nach dem Login siehst du die Verzeichnisse, die du in /srv/assets angelegt hast.
Filebrowser zeigt sie automatisch an und ermöglicht dir den Upload, das Verschieben und Löschen von Dateien direkt im Browser.

Tip

Über das Zahnrad-Symbol oben rechts kannst du neue Benutzer anlegen.
Lege mindestens einen zusätzlichen Benutzer mit eingeschränkten Rechten an, wenn du den Zugriff an andere weitergeben möchtest.

Schritt 7 – Nginx für Dateiauslieferung konfigurieren

Neben der Verwaltungsoberfläche soll der Container die Inhalte auch öffentlich bereitstellen können.
Dazu wird Nginx so konfiguriert, dass er die Dateien aus /srv/assets als statische Inhalte ausliefert.

Öffne die Konfigurationsdatei:

nano /etc/nginx/sites-available/assets.conf

Füge folgenden Inhalt ein:

server {
    listen 80;
    server_name assets.local;

    root /srv/assets;
    index index.html;

    location / {
        autoindex on;
        autoindex_exact_size off;
        autoindex_localtime on;
    }

    location ~ /\. {
        deny all;
    }
}

Datei speichern (Strg + O, Enter, Strg + X) und aktivieren:

ln -s /etc/nginx/sites-available/assets.conf /etc/nginx/sites-enabled/
nginx -t
systemctl restart nginx

Wenn der Test (nginx -t) mit „syntax is ok“ und „test is successful“ endet, ist die Konfiguration gültig.

Nun kannst du prüfen, ob Nginx die Dateien korrekt ausliefert:

http://10.0.0.12/

Im Browser sollte jetzt ein automatisches Verzeichnislisting mit deinen Medien erscheinen.
Bilder und Videos lassen sich direkt öffnen oder herunterladen.

Note

Dieses lokale Verzeichnislisting wird später über den Nginx Proxy Manager abgesichert und mit HTTPS versehen.
Innerhalb des Netzwerks kannst du es jedoch schon jetzt nutzen, um schnell auf die Dateien zuzugreifen.

Schritt 8 – Einbindung in Nginx Proxy Manager (NPM)

Nachdem der Container intern erfolgreich getestet wurde, kann er jetzt über den Nginx Proxy Manager erreichbar gemacht werden.
Damit erhält Filebrowser eine eigene Subdomain mit HTTPS-Zertifikat und ist über eine feste Adresse erreichbar.

Important

Führe diesen Schritt erst durch, wenn du Filebrowser bereits per IP und Port getestet hast.
Nur so kannst du sicherstellen, dass eventuelle Fehler eindeutig auf den Proxy und nicht auf den Container zurückzuführen sind.

1. Proxy-Host für Filebrowser anlegen

Öffne das Dashboard des Nginx Proxy Manager.
Klicke auf Add Proxy Host.
Trage folgende Werte ein:

Feld	Wert
Domain Names	`assets-admin.deinedomain.tld`
Scheme	`http`
Forward Hostname / IP	IP-Adresse des Containers
Forward Port	`8080`
Block Common Exploits	aktivieren
Websockets Support	aktivieren

Wechsle anschließend in den Reiter SSL:

Request a new SSL Certificate → aktivieren
Force SSL → aktivieren
HTTP/2 Support → aktivieren

Speichern mit Save.

2. Proxy-Host für öffentliche Dateiausgabe anlegen

Wiederhole den Vorgang mit den folgenden Werten:

Feld	Wert
Domain Names	`assets.deinedomain.tld`
Scheme	`http`
Forward Hostname / IP	IP-Adresse des Containers
Forward Port	`80`
Block Common Exploits	aktivieren

SSL-Einstellungen wie oben übernehmen.

Tip

Du kannst die interne Verwaltungsoberfläche (assets-admin) durch Basic-Auth oder IP-Access-Lists zusätzlich absichern.
Die öffentliche Dateiausgabe (assets) sollte hingegen ohne Authentifizierung erreichbar sein, damit andere Systeme darauf zugreifen können.

3. Verbindung prüfen

Öffne im Browser:

https://assets-admin.deinedomain.tld

Wenn die Filebrowser-Anmeldung erscheint, funktioniert die Weiterleitung korrekt.
Anschließend testest du die öffentliche Auslieferung über:

https://assets.deinedomain.tld

Im Browser sollte jetzt das automatische Verzeichnislisting erscheinen, das Nginx bereitstellt.

Note

Beide Adressen laufen über denselben Container, jedoch auf unterschiedlichen Ports.
Der Proxy Manager trennt Verwaltung (Port 8080) und Dateiauslieferung (Port 80) logisch voneinander.

Schritt 9 – Benutzerverwaltung und Rechte in Filebrowser

Filebrowser unterstützt eine integrierte Benutzerverwaltung.
Damit kannst du gezielt festlegen, wer Zugriff auf welche Bereiche innerhalb des Containers hat.
So verhinderst du unbeabsichtigte Änderungen oder versehentliches Löschen von Dateien.

1. Benutzerübersicht öffnen

Melde dich über die Subdomain oder IP im Filebrowser an und klicke oben rechts auf dein Profilbild → Benutzer.
Hier kannst du neue Benutzer anlegen oder bestehende verwalten.

2. Neuen Benutzer anlegen

Klicke auf Neu.
Trage einen Benutzernamen und ein Passwort ein.
Wähle im Feld Verzeichnis das Root-Verzeichnis des jeweiligen Benutzers, z. B.
```
/srv/assets/overlays
```
Setze die Berechtigungen nach Bedarf:
- Can Delete: Benutzer darf Dateien löschen
- Can Rename: Benutzer darf Dateien umbenennen
- Can Create: Benutzer darf neue Dateien und Ordner anlegen
- Can Upload: Benutzer darf Dateien hochladen
- Admin: Vollzugriff auf alle Bereiche

Tip

Erstelle keine Admin-Benutzer für alltägliche Arbeiten.
Für Uploads und Korrekturen reichen Benutzer mit eingeschränkten Rechten aus.

3. Benutzerrollen strukturieren

Für den Betrieb im UCC hat sich folgende Struktur bewährt:

Benutzer	Verzeichnis	Rechte	Zweck
admin	`/srv/assets`	Vollzugriff	Systempflege und Strukturverwaltung
upload	`/srv/assets/_upload`	Upload, Create, Rename	Upload von neuen Dateien
readonly	`/srv/assets`	Nur Lesen	interner Zugriff durch andere Dienste

Diese Rollenverteilung sorgt dafür, dass die Struktur stabil bleibt und nur definierte Benutzer Änderungen vornehmen können.

4. Änderungen testen

Melde dich testweise mit einem eingeschränkten Benutzer an und prüfe:

Upload einer Datei
Anlegen eines Ordners
Versuch, eine Datei außerhalb des zugewiesenen Pfades zu öffnen

Wenn Filebrowser die Berechtigungen korrekt setzt, kann der Benutzer nur innerhalb seines Bereichs arbeiten.

Important

Änderungen an der Benutzerverwaltung werden sofort aktiv.
Ein Neustart des Dienstes ist nicht erforderlich, sobald du einen Benutzer anlegst oder Rechte änderst.

Schritt 10 – Sicherheit und Zugriffsbeschränkung

Da Filebrowser direkten Schreibzugriff auf das Dateisystem ermöglicht, ist eine sichere Konfiguration zwingend notwendig.
Unabhängig davon, ob der Zugriff intern oder über das Internet erfolgt, müssen die folgenden Sicherheitsmaßnahmen umgesetzt werden.

1. Standard-Admin sichern

Der Benutzer admin wird bei der Installation automatisch angelegt.
Wenn du diesen Account weiterhin nutzt, ändere das Passwort auf ein sicheres, langes Kennwort mit mindestens 16 Zeichen.
Alternativ solltest du den Standard-Account vollständig entfernen und einen eigenen Administrator mit eindeutigem Namen anlegen.

Admin löschen:

filebrowser users rm admin

Neuen Administrator anlegen:

Melde dich im Filebrowser mit einem bestehenden Benutzer an.
Öffne oben rechts das Menü → Benutzerverwaltung.
Klicke auf Neu.
Gib einen eindeutigen Benutzernamen an (z. B. systemadmin).
Trage ein sicheres Passwort ein.
Wähle als Verzeichnis /srv/assets.
Aktiviere den Schalter Adminrechte.
Speichere mit Erstellen.
Melde dich ab und anschließend mit dem neuen Benutzer wieder an, um die Anmeldung zu prüfen.

Important

Verwende für den Adminzugang keine generischen Namen wie admin, root oder file.
Diese sind die ersten Zielnamen bei automatisierten Loginversuchen.

2. Zugriff über NPM absichern

Im Nginx Proxy Manager kann der Zugang zu assets-admin.deinedomain.tld zusätzlich geschützt werden.
Das reduziert die Angriffsfläche erheblich und blockiert unautorisierte Verbindungen bereits auf Proxy-Ebene.

Öffne im Dashboard den Proxy-Host für assets-admin.
Wechsle in den Reiter Access List.
Klicke auf Add Access List und konfiguriere:
- Access Authorization: aktivieren
- Benutzername und Passwort vergeben
- IP-Whitelist (optional):
  Wenn du den Zugriff auf Filebrowser zusätzlich auf dein Heimnetz begrenzen willst,
  trage hier den Adressbereich deines lokalen Netzwerks ein.
  Beispiel für ein typisches Heimnetz: 192.168.100.0/24
  (bedeutet: alle Geräte zwischen 192.168.100.1 und 192.168.100.254 dürfen zugreifen)
  Wenn du dir unsicher bist, kannst du diesen Schritt auch weglassen –
  der Zugang bleibt dann über Benutzername und Passwort geschützt.
Speichere die Liste und wähle sie anschließend für den Proxy-Host aus.

Damit ist Filebrowser bereits vor dem eigentlichen Login geschützt.
Zugriffe ohne gültige NPM-Anmeldung oder außerhalb der Whitelist werden direkt blockiert.

Note

Diese doppelte Authentifizierung – NPM + Filebrowser – ist ausdrücklich gewollt.
Selbst bei versehentlich schwachen Filebrowser-Logins schützt NPM zuverlässig vor externem Zugriff.

3. Portzugriff einschränken

Filebrowser läuft intern auf Port 8080, Nginx auf Port 80.
Diese Ports dürfen nicht von außen erreichbar sein.
Der Zugriff erfolgt ausschließlich über den Nginx Proxy Manager.

Damit kein direkter Zugriff aus dem Internet möglich ist, aktivierst du im Container die Firewall UFW und erlaubst nur dein internes Netzwerk.

Beispiel für ein typisches Heimnetz:

Wenn dein internes Netz z. B. im Bereich 192.168.100.x liegt, lautet die Regel:

apt install ufw -y
ufw allow from 127.0.0.1
ufw allow from 192.168.100.0/24
ufw deny 8080
ufw deny 80
ufw enable

Damit dürfen nur Geräte aus deinem Heimnetz (z. B. dein PC oder OBS-Rechner) direkt auf den Container zugreifen.
Alle externen Verbindungen werden blockiert, außer sie kommen über den Proxy Manager mit gültigem Zertifikat.

Note

Ersetze den Bereich 192.168.100.0/24 durch dein eigenes Netzwerk, falls du einen anderen IP-Bereich verwendest.
Du findest diesen Wert in Proxmox unter Network oder auf deinem Router.

Important

Prüfe nach dem Aktivieren der Firewall sofort, ob du den Container noch über Proxmox oder SSH erreichst.
Eine falsche Regel kann dich komplett aussperren.

4. Dienststatus regelmäßig prüfen

Überprüfe regelmäßig, ob die zentralen Dienste aktiv sind:

systemctl status filebrowser
systemctl status nginx

Wenn einer der Dienste gestoppt wurde oder „failed“ anzeigt, starte ihn neu:

systemctl restart filebrowser
systemctl restart nginx

Tip

Der Asset-LXC ist dauerhaft aktiv.
Eine Kontrolle im Rahmen der wöchentlichen Systempflege genügt, um mögliche Probleme frühzeitig zu erkennen.

Schritt 11 – Funktionstest

Bevor du den Container dauerhaft nutzt oder in OBS einbindest, musst du prüfen, ob alles korrekt läuft.
Der Funktionstest besteht aus zwei Teilen: erst direkt über die IP-Adresse, dann über den Proxy.

1. Interner Test – direkter Aufruf

Damit du sicher sein kannst, dass Filebrowser selbst richtig funktioniert, wird der erste Test ohne Proxy durchgeführt.
So lässt sich eindeutig unterscheiden, ob ein Fehler später vom Container oder vom Nginx Proxy Manager stammt.

So findest du die IP-Adresse deines Asset-LXC:

Öffne in Proxmox den Container mit der Bezeichnung asset.
Klicke auf Network (links in der Menüleiste).
In der Zeile IPv4 Address steht die interne Adresse, z. B. 192.168.100.30.

Mit dieser Adresse öffnest du Filebrowser direkt im Browser.
Setze dabei deine eigene IP ein:

http://<IP-des-Asset-LXC>:8080

Beispiel:

http://192.168.100.30:8080

Wenn die Login-Seite erscheint, läuft Filebrowser korrekt.

Melde dich mit deinem Administrator-Account an und überprüfe:

Die Ordnerstruktur (overlays, videos, sounds, projects, _meta) wird angezeigt.
Das Hochladen einer Testdatei funktioniert.
Eine hochgeladene Datei lässt sich wieder herunterladen oder öffnen.
Rechtefehler wie „permission denied“ treten nicht auf.

Note

Wenn der Login oder Upload nicht funktioniert, liegt der Fehler im Container selbst.
In diesem Fall Proxy-Einbindung noch nicht aktivieren, sondern zuerst die interne Funktion reparieren.

2. Test über den Nginx Proxy Manager

Wenn der interne Test erfolgreich war, erfolgt der Aufruf über die eingerichteten Subdomains:

https://assets-admin.deinedomain.tld
https://assets.deinedomain.tld

assets-admin führt zur Filebrowser-Oberfläche.
assets zeigt die öffentliche Dateiausgabe (Verzeichnislisting).

Öffne eine Datei im Browser.
Wenn sie sofort geladen wird und in der Adresszeile https:// steht, ist die verschlüsselte Verbindung aktiv.

Tip

Sollte assets zwar erreichbar sein, aber keine Inhalte anzeigen, überprüfe im Nginx Proxy Manager den Forward-Port.
Für die Dateiausgabe muss er auf 80 stehen, während Filebrowser über 8080 läuft.

3. Browser-Caching prüfen

Lade die Seite mehrfach neu (z. B. mit Strg + F5).
Wenn die Dateien direkt und ohne merkliche Verzögerung erscheinen, arbeitet das lokale Caching über Nginx korrekt.
Das ist entscheidend für OBS – Overlays und Mediendateien werden dadurch sofort geladen, ohne jedes Mal neu übertragen zu werden.

Important

Der Funktionstest bestätigt, dass dein Container vollständig und stabil läuft.
Erst wenn beide Adressen (intern und über Domain) fehlerfrei reagieren, gilt das Setup als abgeschlossen.

Schritt 12 – Integration mit OBS

Nach erfolgreichem Funktionstest kann der Asset-LXC nun in OBS Studio eingebunden werden.
Damit stehen alle gespeicherten Overlays, Sounds oder Videos direkt als Quelle zur Verfügung – ohne Cloud-Dienste oder manuelle Uploads.

1. Vorbereitung

Vergewissere dich, dass:

Der Container stabil läuft und per Domain erreichbar ist.
Die Subdomain assets.deinedomain.tld im Browser funktioniert.
Deine Overlays oder Medien im Filebrowser-Ordner /srv/assets/overlays liegen.

Nur so kann OBS die Dateien korrekt laden.

Note

Alle URLs werden im lokalen Netzwerk oder über HTTPS ausgeliefert.
Eine aktive Internetverbindung ist für die Nutzung innerhalb des Heimnetzes nicht erforderlich.

2. Overlay als Browserquelle einbinden

Öffne in OBS das Szenenfenster.
Klicke auf das „+“ unter den Quellen → Browser.
Vergib einen eindeutigen Namen, z. B. Chat Overlay oder Followerbanner.
Im Feld URL trägst du den vollständigen Pfad zur Overlay-Datei ein:

https://assets.deinedomain.tld/overlays/chat.html

Setze die Breite und Höhe entsprechend der Overlay-Größe (z. B. 1920 × 1080 px).
Aktiviere „Lokale Datei“ nicht – die Datei wird direkt vom Asset-Server geladen.
Klicke auf OK.

Das Overlay wird sofort geladen und angezeigt.
Wenn du im Filebrowser eine Änderung an der Datei vornimmst (z. B. Text, Grafik, CSS), genügt in OBS ein Rechtsklick → Aktualisieren, um die neue Version zu sehen.

Tip

Über das Kontextmenü → „Browser neu laden, wenn Szene aktiviert wird“ kannst du sicherstellen,
dass jedes Overlay beim Szenenwechsel automatisch aktualisiert wird.

3. Statische Medien einbinden

Für Videos, Sounds oder Hintergrundgrafiken gilt dasselbe Prinzip.
Beispiele:

Medientyp	URL-Beispiel	OBS-Quelle
Hintergrundvideo	`https://assets.deinedomain.tld/videos/intro.mp4`	Medienquelle
Soundeffekt	`https://assets.deinedomain.tld/sounds/alert.mp3`	Medienquelle
Grafik	`https://assets.deinedomain.tld/overlays/logo.png`	Bildquelle

OBS lädt die Dateien direkt vom Asset-Server.
Das reduziert lokale Speicherlast und sorgt dafür, dass alle Assets zentral gepflegt werden.

Note

Wenn ein Asset nicht geladen wird, prüfe zunächst, ob die URL im Browser funktioniert.
Wenn sie dort korrekt angezeigt wird, liegt das Problem in OBS (z. B. Cache).
In diesem Fall die Quelle löschen und erneut anlegen.

4. Verhalten im lokalen Netzwerk

Wenn OBS und der Asset-LXC im selben LAN laufen, erfolgt der Zugriff mit minimaler Latenz.
Der Aufruf über HTTPS bleibt bestehen, die Datenübertragung erfolgt aber ausschließlich intern.
Es entstehen keine spürbaren Verzögerungen – selbst große Overlays oder Videos laden nahezu sofort.

Important

Für Liveproduktionen sollten Overlays, Sounds und Grafiken immer lokal über den Asset-LXC eingebunden werden.
Dadurch entfällt die Abhängigkeit von externen Servern, und du behältst die volle Kontrolle über deine Stream-Assets.

Troubleshooting & Tipps

Auch wenn der Asset-LXC im Normalbetrieb sehr stabil läuft, können nach der Einrichtung kleinere Probleme auftreten.
Die folgenden Punkte decken die häufigsten Ursachen ab und zeigen, wie du sie systematisch behebst.

Filebrowser nicht erreichbar

Wenn die Login-Seite nicht lädt oder der Browser „Verbindung fehlgeschlagen“ meldet:

In Proxmox prüfen, ob der Container läuft.
Falls gestoppt → Start klicken.
In der Konsole prüfen, ob der Dienst aktiv ist:
```
systemctl status filebrowser
```
Wenn der Dienst „inactive“ oder „failed“ anzeigt:
```
systemctl restart filebrowser
```
Direkt im Browser testen:
```
http://<IP-des-Asset-LXC>:8080
```
Wenn das funktioniert, liegt das Problem beim Proxy (Domain oder SSL-Zertifikat prüfen).

Tip

Nach einem Neustart benötigt Filebrowser bis zu 10 Sekunden, bevor die Login-Seite wieder erreichbar ist.

Wenn nach dem Einloggen ein leeres Verzeichnis angezeigt wird:

Prüfe, ob der Benutzer im richtigen Pfad arbeitet:
Menü → Benutzerverwaltung → Benutzer → Feld Verzeichnis
Der Pfad muss auf /srv/assets oder einen Unterordner zeigen.

Überprüfe die Berechtigungen:

ls -ld /srv/assets

Eigentümer muss www-data sein:

chown -R www-data:www-data /srv/assets

Note

Filebrowser zeigt nur Inhalte an, auf die der Benutzer Zugriff hat.
Wenn der Pfad leer oder falsch gesetzt ist, bleibt die Oberfläche leer.

Kein Zugriff über Subdomain

Wenn https://assets.deinedomain.tld oder https://assets-admin.deinedomain.tld nicht erreichbar ist:

Im Nginx Proxy Manager den Proxy-Host öffnen.
Forward Hostname / IP prüfen – dort muss die IP des Asset-LXC stehen.
Forward Port prüfen –
- 8080 für Filebrowser
- 80 für öffentliche Dateiausgabe
SSL-Zertifikat kontrollieren – ggf. erneuern über Renew Certificate.

Tip

Wenn beide Domains gleichzeitig ausfallen, liegt der Fehler fast immer an einer DNS-Änderung oder einem abgelaufenen Zertifikat.

Upload bricht ab oder lädt nicht

Wenn der Upload von größeren Dateien fehlschlägt oder einfriert:

Prüfen, ob noch genügend Speicherplatz verfügbar ist:
```
df -h /srv/assets
```
Wenn weniger als 1 GB frei ist, Dateien löschen oder Speicher erweitern.
Prüfen, ob Filebrowser genügend Rechte hat:
```
systemctl restart filebrowser
```
Browser-Cache leeren und Upload erneut testen.

Note

Filebrowser lädt Dateien vollständig in den RAM, bevor sie geschrieben werden.
Wenn der Container zu wenig Arbeitsspeicher hat, kann der Upload abbrechen.

Verzeichnislisting zeigt keine Vorschau

Wenn du https://assets.deinedomain.tld öffnest und nur Text statt einer Übersicht siehst:

Stelle sicher, dass Nginx mit aktiviertem Autoindex läuft:

nano /etc/nginx/sites-available/assets.conf

Prüfe, ob folgender Block enthalten ist:

autoindex on;
autoindex_exact_size off;
autoindex_localtime on;

Danach:

nginx -t
systemctl restart nginx

Tip

Wenn du lieber ein strukturiertes Weblayout möchtest, kann später eine eigene HTML-Startseite unter /srv/assets/index.html hinterlegt werden.

Filebrowser startet nach Reboot nicht automatisch

Wenn Filebrowser nach einem Neustart nicht läuft:

Dienststatus prüfen:

systemctl is-enabled filebrowser

Wenn „disabled“:

systemctl enable filebrowser
systemctl start filebrowser

Funktion mit Browseraufruf verifizieren:
```
http://<IP-des-Asset-LXC>:8080
```

Important

Wenn Filebrowser manuell über den CLI-Befehl gestartet wurde, läuft er nur temporär.
Der Dienst muss eingerichtet und aktiviert sein, damit er nach jedem Neustart automatisch startet.

Regelmäßige Kontrolle

Damit der Container langfristig stabil bleibt:

Einmal pro Monat Systemupdates durchführen:
```
apt update && apt upgrade -y
```
Datei- und Benutzerrechte prüfen
Speicherplatz regelmäßig überwachen (df -h)
Backups von /srv/assets in Kopia oder ein externes Laufwerk einbinden

Tip

Eine einfache Routine:

Monatlich Updates

Wöchentlich Funktionstest

Nach jedem größeren Upload ein Backup auslösen
Damit bleibt der Asset-LXC wartungsarm und jederzeit einsatzbereit.

Abschluss

Der Asset-LXC stellt die zentrale Ablage für alle Streaming- und Produktionsdateien bereit.
Mit Nginx und Filebrowser ist ein System entstanden, das sowohl für Einzelanwender als auch für größere Content-Projekte geeignet ist.
Es kombiniert einfache Bedienung mit direktem Zugriff auf alle wichtigen Assets – ohne Abhängigkeit von Cloud-Diensten oder Drittanbietern.

Die Verbindung mit OBS ermöglicht eine nahtlose Integration von Overlays, Sounds, Grafiken und Videodateien direkt aus dem eigenen Netzwerk.
Damit entfallen manuelle Uploads oder externe Links – Änderungen werden sofort wirksam, sobald die Dateien im Filebrowser aktualisiert werden.

Ein korrekt eingerichteter Asset-LXC bietet:

Zentrale Verwaltung aller Mediendateien
Direkten Zugriff über HTTPS und klare Benutzerrechte
Sichere Authentifizierung über den Nginx Proxy Manager
Lokale Performance ohne externe Abhängigkeiten
Erweiterbarkeit durch zusätzliche LXC-Container oder Automatisierung über n8n

Note

Der Asset-LXC ist bewusst modular aufgebaut.
Er funktioniert eigenständig, kann aber in späteren Kapiteln weiter ausgebaut werden – z. B. durch automatische Synchronisierung mit Cloudspeichern, Integration in Produktionsabläufe oder automatisierte Asset-Distribution für mehrere Streaming-PCs.

Mit Abschluss dieses Kapitels steht ein vollständig funktionsfähiger und abgesicherter Dateiserver zur Verfügung,
der die Grundlage für alle visuellen und akustischen Inhalte innerhalb des UCC bildet.
Er ist damit ein zentrales Element der gesamten Infrastruktur – klein, effizient und jederzeit erweiterbar.

32 KiB Raw Permalink Blame History Unescape Escape