Der Auslöser: Eine vernünftige Entscheidung mit unerwarteten Konsequenzen
Vor etwa drei Monaten hat Synology mit einem DSM-Update den USB-Treiber-Support generell eingeschränkt. USB-Geräte lassen sich seitdem nicht mehr an Docker-Container durchreichen.
Ich will das an dieser Stelle fair einordnen: Das ist keine böswillige Entscheidung. Synology entwickelt sich zunehmend in Richtung eines sicherheitsorientierten Systems und das ist grundsätzlich richtig. Die Bedrohungslage hat sich in den letzten Jahren massiv verändert. 2008 konnte noch jeder Scriptkiddie mit minimalen Kenntnissen Systeme kompromittieren. Heute nimmt das Security-Mindset in der Industrie zu – hoffentlich nicht nur auf dem Papier.
Aber hier liegt das eigentliche Problem mit Synologys Entscheidung: Wer Docker-Container auf einem NAS betreibt, Compose-Files schreibt und USB-Passthrough konfiguriert, ist per Definition kein 0815-User. Diese Restriktion schützt genau die falsche Zielgruppe. Der Durchschnittsnutzer, der tatsächlich geschützt werden müsste, betreibt kein Docker. Der Power-User, der es tut, kann das Risiko selbst einschätzen und wird durch die Maßnahme gegängelt.
Das ist ein klassisches Problem von One-size-fits-all Security.
Das gleiche Muster sieht man übrigens auch bei Sysadmins die Docker „absichern“ wollen. Plötzlich gibt es Shell-Scripte und Bash-Wrapper die Docker-Befehle einschränken, eigene Orchestration-Layer die Standards aufbrechen, und Custom-Lösungen die niemand außer dem Urheber versteht. Das eigentliche Problem dabei ist meist kein Security-Problem sondern eine Frage ob man Docker nach Best Practices und etablierten Standards betreibt – oder ob man anfängt das Rad neu zu erfinden weil man den Standards nicht traut. Wer Container nach Best Practices aufsetzt, mit definierten Berechtigungen, vernünftigen Netzwerk-Segmentierungen und standardisierten Compose-Files, braucht keine Custom-Shell-Scripte als Sicherheitsnetz. Wer Standards aufbricht und dann mit eigener Orchestration flickt, hat am Ende etwas gebaut das unwartbar ist und dabei die eigentlichen Vorteile von Docker vollständig untergräbt.
Mein konkretes Problem
Ich betreibe seit Jahren Home Assistant auf meinem Synology NAS. Für die Zigbee-Integration benötige ich einen USB-Dongle, der an den Docker-Container durchgereicht wird. Nach dem Update: nicht mehr möglich.
Dazu kommt ein weiterer Kontext, der die Entscheidungsfindung erheblich beeinflusst hat: Mein NAS ist keine Spielwiese. Ich habe in den letzten Jahren konsequent auf eine digitale Infrastruktur umgestellt. Über 90 Prozent meiner Papierdokumente sind eingescannt und liegen auf dem NAS: Verträge, Behördenschreiben, persönliche Unterlagen. Ein NAS das durch einen fehlgeschlagenen Workaround nicht mehr bootet ist in meinem Fall kein technisches Ärgernis. Es wäre ein echter, nicht wiederherstellbarer Datenverlust.
Warum ich nicht einfach einen Workaround genutzt habe
Mein erster Instinkt war natürlich: gibt es einen offiziellen Weg bei Synology? Nein. Gibt es Workarounds? Ja, Custom Files, Third-Party Repositories, inoffizielle Packages. Ich habe drei Monate lang recherchiert und abgewogen.
Das Risiko war nicht akzeptabel. Wer vertrauliche Daten auf einem System liegen hat und praktisch papierlos lebt, kann keine experimentellen Patches auf kritischer Infrastruktur fahren. Die Angriffsfläche erhöhen genau dort, wo man sie minimieren will, das widerspricht jedem vernünftigen Security-Gedanken.
Die Konsequenz: Eigene Hardware, eigener Stack, eigene Kontrolle.
Eine Frage der Haltung: Workarounds und technische Schulden
Ich habe in vielen Unternehmen dasselbe Muster beobachtet: Statt eine vernünftige Lösung anzugehen, wird ein Workaround gebaut. Dann ein Workaround für den Workaround. Die Infrastruktur wird unwartbar, niemand versteht mehr warum etwas so gewachsen ist wie es ist, und irgendwann ist der Aufwand eine saubere Lösung einzuführen so hoch dass niemand mehr anfängt.
Das frustrierende daran: In den meisten Fällen wäre die Zeit da gewesen es richtig zu machen. Und wenn man es vernünftig argumentiert – Wartungsaufwand, technische Schulden, langfristige Stabilität, bekommt man die Zeit auch. Technische Schulden sind keine abstrakte Metapher. Sie sind reale Mehrarbeit die irgendwann bezahlt werden muss, mit Zinsen.
Privat wie beruflich gehe ich lieber saubere Wege. Die kosten am Anfang mehr Zeit. Aber diese Zeit lässt sich verargumentieren, und sie zahlt sich aus. Ein System das ich in zwei Jahren noch verstehe, das sich ohne Angst vor Seiteneffekten anfassen lässt, das wartbar bleibt: Das ist mehr wert als eine schnelle Lösung die drei Monate später niemand mehr anfassen will.
Das war auch die Entscheidung gegen den Synology-Workaround. Nicht weil ich keine Lust hatte. Sondern weil ich weiß wie solche Geschichten enden.
Die Suche nach der richtigen Hardware und warum der Markt gerade eine Katastrophe ist
Mein erster Plan: Mini-PC kaufen, Problem lösen, weiter. Was folgte war eine mehrwöchige Recherche die mich eines gelehrt hat, der Markt für Homelab-Hardware ist 2026 in einem desolaten Zustand.
Raspberry Pi 5: 230 € für 8 GB RAM. Fertig ausgestattet schnell bei 300 €. Für ARM-Architektur, auf der Proxmox nicht läuft, viele Docker-Images Probleme machen und Virtualisierungsmöglichkeiten stark eingeschränkt sind. Vor ein paar Jahren war der Pi der günstige Einstieg. Heute ist das Preis-Leistungs-Verhältnis nicht mehr zu rechtfertigen.
N100/N150 Mini-PCs: Ständig ausverkauft oder von Marken mit bekannten Kühlproblemen im Dauerbetrieb. Selbst die c’t vertraut diesen Geräten nicht für stabile 24/7-Nutzung. Wer ein System aufbaut das einfach laufen soll, braucht keine Hardware die nach sechs Monaten thermische Probleme bekommt.
Refurbished Business-Hardware (ThinkCentre, EliteDesk): Für 7-8 Jahre alte Hardware werden heute 150-200 € aufgerufen. Der Homelab-Hype hat die Preise nach oben getrieben. Hardware die vor drei Jahren für 60 € wegging kostet heute das Dreifache.
RAM-Preise 2026: 16 GB DDR4 SODIMM kosten aktuell ~100 €. 24 GB Desktop DDR4 liegen bei fast 500 €. KI-Nachfrage auf NAND und RAM-Märkten lässt grüßen.
Neue seriöse Hardware (ASUS NUC, GMKtec mit EU-Support): Schnell bei 280-350 €: für Hardware die oft auf 2019er Architektur basiert. Und bei chinesischen Marken mit deutschem Lager: Support und Garantieabwicklung laufen trotzdem über China.
Die Lösung die schon da war
Nach wochenlanger Suche der offensichtliche Blick in die Ecke: Mein alter Gaming-Tower. Seit drei Jahren nicht angeschaltet. Letzter Bootversuch endete mit einem Windows-Update das irgendetwas zerstört hatte, keine Lust gehabt, Rechner weggestellt.
Drin: i9 KF-Prozessor, 24 GB DDR4 Corsair Vengeance, GTX 2060, Seasonic Focus Gold Netzteil, be quiet! Dark Rock Pro. Hardware die neu heute locker 1.000 € kosten würde und als Homeserver nie auch nur annähernd ausgelastet sein wird.
Die Entscheidung war klar. Neues kompaktes Gehäuse (das alte war nach Jahren als offene Katzenburg nicht mehr zu retten), neuer flacher CPU-Kühler, neue NVMe SSD. Linux drauf, fertig. Nachhaltiger als ein neues Gerät zu kaufen, und deutlich leistungsstärker als jeder Mini-PC im Budget.
Der einzige Mehraufwand: Die Stromkosten. Ein i9 im Server-Idle verbraucht realistisch 40-60W, ein N150 Mini-PC 6-10W. Das sind ~100 € mehr im Jahr. Angesichts der Hardware die bereits vorhanden war und der Tatsache dass 24 GB DDR4 neu fast 500 € kosten, die Rechnung geht trotzdem auf.
Der Stack: seit einer Woche in Betrieb
Ich wollte keine komplexe Lösung die ich ständig warten muss. Als Software-Engineer mit 15 Jahren Berufserfahrung verbringe ich genug Zeit mit IT. Privat soll die Infrastruktur laufen und vergessen werden. Seit etwa einer Woche tut sie genau das.
Proxmox VE als Hypervisor. Kostenlos, keine Lizenzproblematik, kein Vendor Lock-in. Läuft stabil.
Home Assistant OS als VM : nicht als Docker-Container, sondern als vollständige HAOS-Instanz mit Supervisor, offiziellen Add-ons und sauberem Update-Pfad. Zigbee läuft über USB-Passthrough, Fritz Smart Home über die Fritz!Box-Integration. Alles an einem Ort statt über fünf verschiedene Apps verteilt – endlich.
OpenClaw als KI-Assistent: läuft via Telegram Bot, ich bin als Owner verifiziert und habe damit erweiterte Rechte. Claude und OpenAI über einen einheitlichen API-Proxy. Das Prinzip funktioniert: Ich beschreibe in natürlicher Sprache was ich will, OpenClaw setzt es um.
Whisper lokal als Docker-Container mit CUDA-Beschleunigung auf der GTX 2060, Speech-to-Text ohne Cloud, bewusst so eingerichtet um keine API-Token für Audiotranskription zu verbrauchen. Erst der transkribierte Text geht an OpenClaw weiter.
AdGuard Home läuft als primärer DNS über die Fritz!Box, Werbeblocker und lokale Domain-Auflösung in einem. Was dabei passiert ist: Ich habe AdGuard so gut konfiguriert dass er kurzzeitig meine eigene Fritz!Box als DNS-Anfrage blockiert hat. Das komplette Netz stand vor seiner eigenen Haustür und durfte nicht rein. Nach dem Whitelisten lief wieder alles. Manchmal muss man sich selbst aussperren um zu verstehen was man gebaut hat.
Vaultwarden: migriert vom Synology NAS, läuft stabil, kein Gefrickel mehr.
Traefik als Reverse Proxy für die lokale Entwicklungsumgebung, alle Projekte sind über sprechende lokale Domains erreichbar statt über manuelle Port-Verwaltung. Ein Bug in Traefik v3.0 bis v3.3 hat dabei eine Stunde gekostet – erst v3.7 läuft sauber mit dem neuen Moby v2 Docker-Daemon.
PHPStorm Remote Development über SSH auf eine Debian VM, kein WSL mehr, keine Windows-Eigenheiten, eine saubere Linux-Umgebung die immer läuft.
Tailscale für sicheren Fernzugriff, funktioniert problemlos hinter DS-Lite (Vodafone), kein offener Port, kein DynDNS.
Die Backup-Infrastruktur war bereits vorhanden
Das ist vielleicht der wichtigste Punkt: Ich musste meine Infrastruktur nicht neu erfinden. Die Backup-Strategie war bereits da.
Synology NAS mit RAID 1 empfängt jetzt Proxmox-Snapshots per SMB und bleibt das was es eigentlich immer sein sollte: ein zuverlässiger Datenspeicher, kein Docker-Host.
Dropbox-Sync verschlüsselt läuft bereits, alle wichtigen Daten landen dort automatisch.
Smart Home Geräte laufen bereits in einem eigenen VLAN, Netzwerksegmentierung war von Anfang an Teil des Konzepts.
3-2-1 Backup-Strategie war schon da. Ich musste sie nur um den neuen Server erweitern.
Was OpenClaw bereits gemacht hat und wo es noch hakt
Erste praktische Ergebnisse: OpenClaw hat mit HAOS API-Token und minimalem Kontext eigenständig meine Sonoff Hydrometer mit den Fritz-Thermostaten automatisiert. Entity-IDs selbst herausgefunden, Automation geschrieben, deployed. Ich habe nur die Richtung vorgegeben. Nach einer Woche Betrieb, kosten bei 0.00 $ läuft über das ChatGPT Plus Abo.
Aber ich wäre nicht ehrlich wenn ich nur die Erfolge berichte.
OpenClaw hat ein ernstes Problem mit Persistenz. Alles was ich ihm über Telegram mitteile – Konfigurationen, Einstellungen, HAOS API-Token, Speech-to-Text Konfiguration, vergisst er nach spätestens 24 Stunden. Er bestätigt zuverlässig dass er sich etwas gemerkt hat. Und dann ist es weg.
Das ist kein Nutzerfehler. Ich habe OpenClaw explizit angewiesen seine eigene Konfiguration zu persistieren. Es funktioniert nicht zuverlässig. Das ist eine echte Schwäche eines noch jungen Tools und ein Thema mit dem ich mich demnächst intensiver beschäftigen werde.
Die Nutzung über Telegram als mobiler Assistent funktioniert ansonsten gut. Owner-Verifizierung, natürliche Sprache, Sprachnachrichten über Whisper das Konzept stimmt. Die Persistenz muss noch gelöst werden.
Fazit
Was als USB-Treiber-Problem angefangen hat, ist drei Monate später ein durchdachtes Homelab geworden. Nicht weil ich es so geplant hatte, sondern weil jede Entscheidung die nächste nach sich gezogen hat.
Synology hat etwas Richtiges getan und mich dadurch gezwungen, etwas Besseres aufzubauen. Unabhängigkeit von Herstellerentscheidungen ist mehr wert als man denkt, bis man sie verliert.
Der Tower stand drei Jahre in der Ecke und hätte dort weiter gestanden. Jetzt läuft darauf eine Infrastruktur die ich vollständig kontrolliere, verstehe und nach meinen Anforderungen betreibe. Ohne Vendor Lock-in, ohne Workarounds auf kritischer Infrastruktur, ohne Kompromisse bei der Datensicherheit.
Manchmal ist die beste Lösung die, die schon da war.
