En hälsning från Zima
Tack, sbinske, för att du visade att en användbar hemserver inte behöver börja med specialbyggd serverhårdvara eller erfarenhet av professionell administration. Ditt retro-LAN-party förvandlade överblivna PC-delar till ett ZimaOS-system som kör Docker-tjänster, flera virtuella maskiner, DNS, TeamSpeak och de stödverktyg som behövdes för att få ett gammaldags lokalt nätverksevenemang att fungera.
Vi uppskattar särskilt att du dokumenterade felsökningen lika tydligt som framgångarna. Frysningarna med GT710, instabiliteten hos nätverkskortet, begränsningarna du upptäckte i App Store-arbetsflödet och din efterfrågan på mer flexibla lagringskombinationer är den typ av återkoppling som hjälper till att visa var ett lättviktigt system känns lättillgängligt och var det fortfarande ställer för höga krav på en hobbyanvändare.
— Zima
Möt sbinske
sbinske beskriver sig själv som en icke-professionell teknikanvändare och DIY-hobbyist. Den skillnaden är viktig för den här berättelsen. Han närmade sig inte ZimaOS som en systemadministratör på jakt efter ännu en plattform att jämföra. Han närmade sig det som någon som tycker om att bygga saker, återanvända hårdvara och uppnå ett praktiskt resultat utan att förvandla varje projekt till företagsinfrastruktur.
Innan han bestämde sig för ZimaOS ägnade han lång tid åt att leta efter ett alternativ till Unraid. Det som lockade honom var inte funktionsmässig likvärdighet punkt för punkt. Faktum är att en av sakerna han uppskattade var att ZimaOS kändes lättare och inte försökte vara lika omfattande som Unraid.
Hans projekt från februari 2026 blev ett mycket specifikt test av den idén: kunde ett jämförelsevis lättviktigt hemserveroperativsystem köra den kombination av containrar, virtuella maskiner, nätverk och lagring som behövdes för ett retro-LAN-party?
Ett retro-LAN-party blev testfallet
Servern förbereddes för ett gammaldags LAN-party, där infrastrukturen behövde finnas lokalt och stödja evenemanget utan att vara beroende av en mängd externa tjänster.
När han dokumenterade bygget körde ZimaOS redan två Docker-containrar: en TeamSpeak-server och en DNS-server. Utöver dem fanns tre virtuella maskiner: en ETI-SyncServer, en LanPage-VM och ytterligare en VM avsedd att organisera de återstående tjänsterna kring evenemanget.
Det var den arbetsbelastningen som gjorde projektet mer intressant än ett enkelt NAS-test. Lagring var bara en del av det. Systemet behövde också vara värd för nätverkstjänster och flera isolerade virtuella maskiner samtidigt.
Varför ZimaOS fungerade som ett lättviktigt alternativ till Unraid
sbinskes jämförelse med Unraid var medvetet praktisk. Han förväntade sig inte att ZimaOS skulle återskapa alla Unraids funktioner. Han ville ha ett mindre system som täckte de funktioner han faktiskt behövde och förblev tillräckligt begripligt för att kunna hanteras av en hobbyanvändare.
När hårdvaruproblemen väl var under kontroll var hans helhetsupplevelse positiv. Systemet stabiliserades och hanterade belastningen från det LAN-party som han hade byggt det för.
Den aktuella ZimaOS-dokumentationen beskriver fortfarande virtuella maskiner som en del av plattformen under utveckling, medan det övergripande systemet kombinerar lagring, Docker-applikationer och virtualisering i ett och samma gränssnitt. Det gör sbinskes projekt till ett bra exempel på hur dessa delar kan användas tillsammans i stället för att behandla varje funktion som en separat demonstration.
Det första stora problemet såg ut som att ZimaOS hade hängt sig
Bygget började inte problemfritt. sbinske rapporterade att ZimaOS låste sig helt efter ungefär 20 minuter i drift.
Efter att ha kontrollerat loggarna och testat komponenterna spårade han den första problemomgången till ett gammalt NVIDIA GeForce GT 710. Han försökte installera drivrutiner manuellt via terminalen, men det löste inte problemet. Han experimenterade också med ändringar relaterade till virtuella enheter utan framgång.
Till slut tog han bort grafikkortet, återställde systemet och installerade om ZimaOS utan det. Den rena installationen fungerade återigen korrekt.
Detta bör betraktas som ett kompatibilitetsproblem som rapporterats av en användare på just hans dator, inte som ett generellt påstående om att varje GT 710 är inkompatibelt med alla ZimaOS-versioner. Källan dokumenterar vad som hände i denna konfiguration; den fastställer ingen universell drivrutinsregel.
Att sätta tillbaka GPU:n avslöjade ett mer komplicerat hårdvaruproblem
När sbinske satte tillbaka grafikkortet förändrades beteendet. I stället för att bara se något som verkade vara ett grafikdrivrutinsproblem började datorn upprepade gånger koppla från och återupptäcka hårddiskar och nätverkskort.
Loggarna visade fel, men han kunde inte med säkerhet koppla dem till ett specifikt nätverkskort eller till grafikkortet ensamt. Därför ändrade han felsökningsmetod: ta bort hårdvara, en komponent i taget, och se när systemet slutade klaga.
Den processen ledde till det tydligaste resultatet under hela felsökningen. Systemet var instabilt med tre tillagda nätverkskort plus moderkortets inbyggda nätverksgränssnitt. Med endast två tillagda nätverkskort fungerade datorn bra.
Han misstänkte PCIe-filfördelning – men kunde inte bevisa det
Värden var inte specialbyggd serverhårdvara. Den använde en AMD Ryzen 5 2600, ett MSI B450 Plus-moderkort och 64 GB RAM – i princip överbliven hårdvara som fanns tillgänglig för projektet.
sbinske misstänkte att kombinationen av moderkort, processor, grafikkort och flera nätverksadaptrar kan ha stött på ett problem med PCIe-banor eller resursallokering. Men han fortsatte inte undersökningen tillräckligt långt för att bevisa teorin, eftersom maskinen redan uppfyllde hans behov med två extra nätverkskort.
Den gränsen är viktig. Det lyckade felsökningsresultatet är känt: minska kombinationen av expansionskort så blev systemet stabilt. Den exakta grundorsaken, oavsett om den gällde elektricitet, firmware eller allokering av PCIe-banor, är fortfarande en hypotes från skaparen och inte ett bekräftat fel i ZimaOS.
När hårdvaran hade stabiliserats förblev servern stabil
Efter att ha minskat antalet nätverkskort och tagit bort den problematiska hårdvarukombinationen rapporterade sbinske att systemet körde stabilt.
Det förändrade hans syn på projektet. De inledande frysningarna hade fått installationen att verka opålitlig, men det senare beteendet tydde på ett mer komplicerat samspel mellan operativsystemet och en ovanlig samling återanvända datorkomponenter.
För ett DIY-bygge var den skillnaden viktigare än att identifiera en perfekt grundorsak. Han hade nått en konfiguration som kunde hålla LAN-party-tjänsterna igång, och två nätverkskort räckte redan för den roll han hade planerat.
Det var i App Store som ZimaOS kändes mindre användarvänligt än Unraid
Den skarpaste kritiken mot användarvänligheten i sbinskes enkät gällde App Store-upplevelsen för Docker-containrar från tredje part.
Hans referenspunkt var Unraid: installera en App Store, sök efter containern, följ en tydlig beskrivning och ett konfigurationsformulär och installera den sedan. Han ansåg att ZimaOS kunde nå samma resultat, men att installation av en okänd container eller en container från tredje part krävde för mycket kunskap av icke-professionella användare och hobbyister.
Den feedbacken dokumenterades i februari 2026. Den aktuella ZimaOS-dokumentationen säger nu att användare kan importera godtyckliga Docker Compose-YAML-filer, redigera konfigurationer direkt, köra stackar med flera containrar och använda community-underhållna tredjepartsbutiker. Utvecklardokumentationen beskriver också det aktuella arbetsflödet för paketering i App Store betydligt mer detaljerat.
De nyare funktionerna suddar inte ut hans ursprungliga erfarenhet. De ger ett användbart sammanhang: det arbetsflöde han tyckte var för komplicerat var precis ett sådant område som ZimaOS fortsatte att bygga ut senare under 2026.
Lagringsflexibilitet var den andra saknade pusselbiten
sbinske ville också ha större frihet att dela upp flera diskar i olika lagringsgrupper för olika arbetsbelastningar.
Hans exempel var praktiskt: ett par diskar kunde användas som RAID 0 när kapacitet och hastighet var viktigare än redundans, medan ett annat par kunde vara RAID 1 för data som behövde speglas. Hans SyncServer-arbetsbelastning behövde framför allt mer än 4 TB utrymme, men krävde inte samma nivå av dataskydd som viktigare lagring.
Ur hans perspektiv skulle möjligheten att kombinera billigare befintliga diskar till arrayer anpassade efter arbetsbelastning kunna sänka hårdvarukostnaden och göra bättre användning av de diskar som redan fanns till hands.
Den aktuella ZimaOS-dokumentationen omfattar nu RAID 0, RAID 1, RAID 5, RAID 6, JBOD och ZFS. Den offentliga dokumentation som granskades för denna berättelse bekräftar dock inte uttryckligen exakt det arbetsflöde för flera arrayer som sbinske efterfrågade — till exempel att självständigt skapa en tvådiskars RAID 0 och en separat tvådiskars RAID 1 på samma värd via det vanliga användargränssnittet. Därför bevarar denna sida hans önskemål i stället för att hävda att det har lösts helt.
En icke-yrkesverksam användares definition av framgång
Det som gör projektet användbart är att sbinske inte bedömde systemet utifrån hur många avancerade funktioner det erbjöd. Han bedömde det utifrån om det kunde stödja de tjänster han faktiskt ville köra.
Efter felsökningen av hårdvaran var svaret i stort sett ja. ZimaOS var lättare än Unraid, men det var acceptabelt eftersom hans LAN-festserver inte behövde alla Unraid-funktioner. Två Docker-containrar, tre virtuella maskiner, lokal DNS, röstkommunikation, synkronisering och tjänster för evenemangshantering räckte för att göra servern användbar.
Hans invändningar kom från samma praktiska perspektiv. Enklare installation av Docker-containrar från tredje part skulle minska inlärningskurvan. Mer flexibla möjligheter att gruppera diskar skulle kunna sänka hårdvarukostnaden. Bättre kompatibilitet med ovanliga kombinationer av expansionskort för stationära datorer skulle göra projekt med reservhårdvara mindre oförutsägbara.
Historien skrivs fortfarande
sbinskes och Zimas historia skrivs fortfarande. Hans nuvarande projekt började som ett lättviktigt Unraid-alternativ för en retro-LAN-fest och blev ett verklighetstest av hur ZimaOS fungerar på återanvänd stationär hårdvara under en blandad Docker- och VM-arbetsbelastning.
Slutresultatet var inte en perfekt problemfri första installation. Det var ett fungerande DIY-system som uppnåddes genom felsökning på komponentnivå: ta bort GT 710, minska kombinationen av expansionskort, behålla de två nätverkskorten som faktiskt behövdes och gå vidare när maskinen förblev stabil.
För någon som uttryckligen beskriver sig som hobbyist snarare än yrkesperson kan det vara det mest användbara resultatet av projektet. Systemet dolde inte alla tekniska detaljer för honom, men när hårdvarukombinationen förenklades levererade det den enklare hemservermiljö han hade letat efter.
För aktuell plattformskontext, se översikten över ZimaOS-funktioner och den aktuella referensen för RAID-konfiguration.
