Eén verkeerd teken heeft mijn NAS kapotgemaakt—hier leest u hoe ik het terugbracht zonder opnieuw te installeren

Een paar weken geleden liep ik tegen een probleem aan dat ik vroeger nooit had gehad: een kapot fstab-bestand. Mijn Ugreen NAS had een enkel teken dat ervoor zorgde dat mijn fstab-bestand niet gelezen kon worden, waardoor de NAS niet kon opstarten. Hier is hoe ik het heb gered en weer tot leven heb gebracht zonder het besturingssysteem opnieuw te installeren.

Een eenvoudige fout bracht mijn Ugreen NAS uit de lucht

Ik had geen idee totdat een herstart ervoor zorgde dat het opnieuw niet opstartte

Ik heb een enigszins gecompliceerde homelab-opstelling die ik zelf heb gemaakt. Dat betekent dus dat sommige van mijn systemen een beetje onbetrouwbaar werken—vooral mijn Ugreen NAS.

Mijn Ugreen NAS, de iDX6011 Pro, heeft een vrij krachtige processor met de Core Ultra 7. Aan de andere kant heeft mijn hoofdopslagsysteem, een oude Lenovo RD440 rack-mount server die Unraid draait met 12 3,5-inch schijfslots, zwakke 15 jaar oude Xeon-processors.

Dus, voor mijn Plex-opstelling heb ik de mediaopslag op de Lenovo omdat deze 80TB aan opslag over zijn 12 schijven heeft, terwijl de Ugreen zelf Plex draait dankzij zijn solide Intel iGPU voor transcoding. Dit betekent dat ik mijn Unraid-server via het netwerk moet mounten met NFS.

Om de een of andere reden staat Ugreen geen externe NFS-mounts toe binnen UGOS, iets waar ik omheen kon werken door het /etc/fstab-bestand aan te passen—wat uiteindelijk mijn ondergang werd.

Tijdens het bewerken van het fstab-bestand, wat veilig is om vaak te doen, heb ik op de een of andere manier een losstaande ' toegevoegd aan het begin van het bestand. Dit is volkomen onschadelijk wanneer het systeem opstart, en ik merkte de kleine fout nooit op, aangezien ik telkens wanneer ik het fstab-bestand opende, gewoon naar het gedeelte sprong dat ik moest bewerken en daar bewerkte.

Het probleem ontstond toen de stroom uitviel in het huis en ik de server uitschakelde om een harde uitschakeling te voorkomen. Telkens wanneer ik probeerde het systeem opnieuw op te starten, startte het gewoon niet en gaf het een foutmelding op het ingebouwde display. Dat was het moment waarop de paniek begon toe te slaan.

Eigenzinnige en creatieve homelab-projecten
Trivia-uitdaging

Van Pi-holes tot Proxmox-clusters — hoe goed ken jij de wilde wereld van homelab-klussen?

Wat is het belangrijkste doel van het draaien van Pi-hole in een homelab?

Welk hypervisorplatform is het populairst onder homelab-liefhebbers voor het draaien van meerdere virtuele machines op één enkele server?

Wat voor soort software is Nextcloud, die meestal zelf wordt gehost in homelabs?

Wat is een gebruikelijke homelab-toepassing voor oude enterprise switches die goedkoop op eBay zijn gekocht, zoals een Cisco Catalyst?

Wat doet de homelab-tool Grafana voornamelijk?

Wat is een 'NAS' in de context van een homelab, en welk merk wordt het meest geassocieerd met NAS-apparaten die geschikt zijn voor beginners?

Welk open-sourceproject stelt homelabgebruikers in staat om zelf een volledige mediaserver te hosten die films en tv-shows naar bijna elk apparaat kan streamen?

Welk eigenzinnig homelab-project houdt in dat je thuis een miniatuurversie van de routeringsinfrastructuur van het internet opzet, vaak met software zoals BIRD of FRRouting?

Je score

Bedankt voor het spelen!

Paniekerig duwde me ertoe om een oplossing te vinden in plaats van opnieuw te beginnen

Ik gebruikte de NAS al intensief in mijn homelab en had nog geen back-ups ingesteld

Slechts een paar dagen voor dit evenement had ik een ander probleem in mijn homelab dat me ertoe bracht om back-ups op te zetten—alleen, ik had ze nog niet opgezet op het moment dat dit gebeurde. Dus, ik kon het me echt niet veroorloven om de Ugreen NAS volledig te resetten en opnieuw te beginnen toen hij niet meer wilde opstarten. Ik moest het repareren.

Ik raakte zeker in paniek toen ik het probeerde te repareren om 10 uur die avond, terwijl mijn vrouw en ik normaal rond 10:30 uur naar bed gaan. Dus ik werkte op dat moment zeker niet op volle toeren. Ik moest het echter repareren.

Dus, met de hulp van ChatGPT en mijn kennis van Linux-servers, begon ik te achterhalen wat er aan de hand was. Het eerste probleem was het feit dat ik geen SSH-toegang tot het systeem kon krijgen. Het zat op het netwerk, maar SSH was uitgeschakeld omdat de root-gebruiker om veiligheidsredenen geen wachtwoord had ingesteld. Dus moest ik een andere manier vinden om binnen te komen.

Na nog wat meer in paniek te zijn geweest, realiseerde ik me dat ik de NAS op mijn monitor via HDMI kon aansluiten en een toetsenbord kon aansluiten, dus dat is wat ik deed. Zodra ik het toetsenbord en de monitor had aangesloten, kon ik shift en escape indrukken om te proberen de grub-bootloader te bereiken, en dat werkte eigenlijk.

Eenmaal binnen in de grub-bootloader, kon ik het opstartscript bewerken om rw init=/bin/bash aan het einde van de Linux-lijn toe te voegen. Dit stelde me in staat toegang te krijgen tot de native bash-prompt van het systeem bij het opstarten. Zodra ik het besturingssysteem binnen was, kon het echte debuggen beginnen.

Het eerste dat ik moest doen, was uitzoeken waarom het niet opstartte, wat is wanneer ik begon te kijken naar het /etc/fstab bestand dat ik eerder noemde. Ik zag aanvankelijk eigenlijk niets mis met het bestand, omdat het werd weergegeven in een gedeelte van mijn grote monitor ter grootte van het ingebouwde scherm op de Ugreen NAS.

Echter, zodra ik een foto van het fstab-bestand nam en naar ChatGPT stuurde, merkte het probleem meteen op—een losstaande '. Ja, je leest het goed. Aan het begin van mijn fstab-bestand stond een apostrof. Dit betekende dat het systeem het hele fstab-bestand niet kon lezen vanwege één losstaand teken aan het begin van het bestand.

Nu kende ik het probleem, dus het zou een eenvoudige oplossing zijn, toch? Fout. Het bestandssysteem was alleen-lezen aangekoppeld, dus ik kon het fstab-bestand niet zomaar bewerken en verder gaan. Ik moest wat meer werk doen om mijn fout te herstellen. Dus het volgende wat ik moest doen, was ervoor zorgen dat ik daadwerkelijk kon inloggen op een echte root-shell.

Ik moest een wachtwoord instellen voor de root-gebruiker, omdat er nog geen bestond. Dit was eenvoudig met passwd root, en daarna kon ik exec /sbin/init uitvoeren om in te loggen op de root-shell zelf met het nieuwe wachtwoord. In ieder geval was ik nu ergens waar ik vertrouwd mee was.

Het kostte me nogal wat tijd om uit te zoeken hoe ik het systeem kon mounten zodat ik er daadwerkelijk naar kon schrijven, maar het commando dat uiteindelijk werkte was mount -n -o remount,rw -t overlay overlay /. Zodra ik dat commando had uitgevoerd, kon ik het fstab-bestand daadwerkelijk bewerken, het apostrof verwijderen en het systeem weer laten opstarten.

De oplossing zou op bijna elke NAS moeten werken waarbij dit gebeurt

Het is een eenvoudige fout, dus wees klaar met de oplossing als je hem per ongeluk maakt

Hoewel ik dit hele proces op mijn Ugreen NAS heb gedaan, zal hetzelfde proces zeer waarschijnlijk werken met elk ander NAS (of Linux-gebaseerd systeem in het algemeen) dat je bezit.

In wezen is het UGOS-besturingssysteem van Ugreen gewoon Debian Linux dat is aangepast met hun software erbovenop. Dus de oplossingen die ik hier heb toegepast, gelden echt voor de meeste Linux-besturingssystemen.

Het is ook een geweldige herinnering om voorzichtig te zijn bij het bewerken van kernbesturingssysteembestanden op je computer. Ik heb in de loop der jaren talloze fstab-bestanden op verschillende systemen bewerkt, en het was in het verleden nooit een probleem. Maar het koste slechts één verkeerd geplaatst teken om mijn gehele homelab op zijn knieën te brengen.

Werk altijd aan het oplossen van een probleem in plaats van het gewoon opnieuw te installeren

Ik had gewoon het besturingssysteem van mijn Ugreen NAS kunnen herinstalleren en vrij snel weer operationeel kunnen zijn. Dat zou me echter niet de waardevolle les hebben geleerd om het systeem zelf te repareren.

Ik ben zo blij dat ik de tijd heb genomen om het systeem goed te analyseren en weer aan de praat te krijgen in plaats van vroegtijdig op te geven zoals ik de neiging had te doen. Ik heb nu de kennis om andere systemen te repareren waarbij ik in de toekomst mogelijk een soortgelijk probleem tegenkom.