Vorsicht beim Anschluss von USB-Festplatten an unbeaufsichtigte Server
- Christian Süßenguth
- Kurz notiert

Ich kann aus eigener Erfahrung nur davor warnen, USB-Geräte (v.a. USB-Festplatten) an unbeaufsichtigte Server anzuschließen, ohne vorher mehrfach über die potentiellen Folgen nachgedacht zu haben.
In meinem Fall habe ich – für interne VM-Backups – zwei USB-Festplatten an meinen Fujitsu-Server mit PROXMOX angeschlossen. So weit, so problemlos.
Nun habe ich jedoch in der GUI von PROXMOX einen kleinen Fehler gemacht und die gemountete Festplatte mit 8TB versehentlich für eine VM freigegeben. Daraufhin war die Platte nicht mehr ansprechbar und dmesg
warf ganz unterschiedliche Fehler. Vielleicht ist die Platte auch "plötzlich" defekt – die Fehlermeldungen sind da nicht ganz eindeutig. Tut am Ende aber auch nichts zur Sache, denn die Platte ist aktuell nicht mehr nutzbar.
Als erste Maßnahme habe ich daher mittels usbreset
das Gerät zurückgesetzt. Leider hat das nicht wirklich geholfen, denn auch nach dem Reset bleiben die Fehler weiterhin erhalten.
Hier der Auszug aus dmesg
:
Daraufhin habe ich den PROXMOX-Host neu gestartet, da ich mir davon einen umfänglicheren Reset der USB-Festplatte erhofft habe. Doch damit habe ich einen großen Fehler gemacht. Der Host fährt jetzt nämlich überhaupt nicht mehr hoch.
Schaue ich über die Funktion Console Redirection
des iRMC von Fujitsu auf die Maschine, sehe ich, dass das BIOS bei Fehlercode B4 hängen bleibt (BIOS POST Watchdog-Aktion: Power Cycle (Post-Code: 0xB4)
). Welch Überraschung – ein USB-Fehlercode.
Also dachte ich, ich deaktiviere einfach die USB-Ports im BIOS und versuche daraufhin den Server zu starten. Das hat auch geklappt, doch fährt der Host nach diesem Versuch dennoch nicht mehr hoch, da ich in der /etc/fstab
vergessen hatte, den Parameter nobootwait
für den Eintrag der USB-Festplatte zu setzen 🤦.
Damit lande ich (sehr warscheinlich) direkt in einer Rescue-Shell. Leider habe ich bislang die Console Redirection auf Kernel-Ebene nicht aktiviert, so dass ich das nicht verifizieren und in dieser auch nichts ausrichten kann.
Dieser Server wird also nicht mehr booten, bis jemand vor Ort den Stecker der USB-Platte zieht und diese damit zurücksetzt und/oder über direkten Zugriff auf den Server aus der Rescue Shell den Server startet.
Genau so sieht ein DEADLOCK aus 🙈
Was lerne ich daraus?
- Keine USB-Geräte an einen unbeaufsichtigten Server anschließen, solange man diese nicht auch per Remote "stromlos" machen kann, z.B. mit einer per Tasmota fernsteuerbaren Steckdose. In meinem Fall wird es nun eine Nous A5T 3-fach WiFi Steckerleiste werden.
- Kenne deine "Notfall-Werkzeuge" wie
Console Redirection
oderiRMC
, damit du im Falle eines Falles handlungsfähig bleibst. Richte dir dieConsole Redirection
auf Kernel-Ebene vorab ein, auch wenn du meinst, sie nie zu brauchen. nobootwait
ist dein Freund.- Die warscheinlich wichtigste Lernerfahrung: Akzeptiere, dass es in der IT immer mindestens EINEN Fall geben wird, den du vorab NICHT bedacht hast 😜

Hi, ich bin Christian und Inhaber der Firma SWEETGOOD. Mit dem andersGOOD Blog möchte ich auch dich für datensichere IT-Lösungen begeistern. So bringst du dein Unternehmen voran, ohne großen Konzernen deine wertvollen Daten zu liefern. Probiers mal anders!
Kommentarbereich
Die Kommentare sind für dich noch deaktiviert, da du dem Setzen von Cookies bisher nicht zugestimmt hast.
Klicke oben rechts auf "Ja, klar!" und lade die Seite neu, um die Kommentare anzuzeigen.
Seite neu laden