Sbinske and ZimaOS: Building a Retro LAN Party Server

Meet sbinske

sbinske describes himself as a non-professional technology user and DIY hobbyist. That distinction matters to this story. He did not approach ZimaOS as a systems administrator looking for another platform to benchmark. He approached it as someone who enjoys building things, reusing hardware, and getting a practical result without turning every project into enterprise infrastructure.

Before settling on ZimaOS, he spent a long time looking for an alternative to Unraid. What attracted him was not feature-for-feature parity. In fact, one of the things he liked was that ZimaOS felt lighter and did not try to be as extensive as Unraid.

His February 2026 project became a very specific test of that idea: could a comparatively lightweight home-server OS run the mix of containers, virtual machines, networking, and storage needed for a retro LAN party?

A Retro LAN Party Became the Test Case

The server was being prepared for an old-fashioned LAN party, where the infrastructure had to live locally and support the event without depending on a stack of external services.

By the time he documented the build, ZimaOS was already running two Docker containers: a TeamSpeak server and a DNS server. Alongside them were three virtual machines: an ETI-SyncServer, a LanPage VM, and another VM intended to organize the remaining services around the event.

That workload is what made the project more interesting than a simple NAS test. Storage was only one part of it. The system also had to host network services and several isolated virtual machines at the same time.

Why ZimaOS Worked as a Lightweight Unraid Alternative

sbinske's comparison with Unraid was deliberately practical. He did not expect ZimaOS to reproduce every Unraid capability. He wanted a smaller system that covered the functions he actually needed and stayed understandable enough for a hobbyist to work with.

Once the hardware problems were under control, his overall experience was positive. The system settled into a stable state and handled the LAN-party workload he had built around it.

Current ZimaOS documentation still describes virtual machines as an evolving part of the platform, while the broader system combines storage, Docker applications, and virtualization in one interface. That makes sbinske's project a good example of using those pieces together instead of treating each feature as a separate demo.

The First Major Problem Looked Like a ZimaOS Freeze

The build did not begin smoothly. sbinske reported that ZimaOS would completely freeze after roughly 20 minutes of operation.

After checking logs and testing components, he traced the first round of trouble to an old NVIDIA GeForce GT 710. He attempted to install drivers manually through the terminal, but that did not resolve the issue. He also experimented with virtual-drive-related changes without success.

Eventually he removed the graphics card, reset the system, and reinstalled ZimaOS without it. The clean installation ran properly again.

This should be treated as a creator-reported compatibility problem in his specific machine, not as a general claim that every GT 710 is incompatible with every ZimaOS build. The source documents what happened in this configuration; it does not establish a universal driver rule.

Putting the GPU Back Exposed a More Complicated Hardware Problem

When sbinske reintroduced the graphics card, the behavior changed. Instead of only seeing what looked like a graphics-driver problem, the machine began repeatedly disconnecting and rediscovering hard drives and network cards.

The logs showed errors, but he could not confidently attribute them to one specific network adapter or to the graphics card alone. So he changed the troubleshooting method: remove hardware one component at a time and watch for the point where the system stopped complaining.

That process led to the clearest result of the whole debugging session. The system was unstable with three added network cards plus the motherboard's onboard network interface. With only two added network cards, the machine ran well.

He Suspected PCIe Lane Allocation — but Did Not Prove It

The host was not purpose-built server hardware. It used an AMD Ryzen 5 2600, an MSI B450 Plus motherboard, and 64GB of RAM — essentially spare hardware that was available for the project.

sbinske suspected that the combination of motherboard, CPU, graphics card, and several network adapters may have run into a PCIe-lane or resource-allocation problem. But he did not continue the investigation far enough to prove that theory because the machine already met his needs with two additional network cards.

That boundary is important. The successful troubleshooting result is known: reduce the expansion-card combination and the system became stable. The exact electrical, firmware, or lane-allocation root cause remains a hypothesis from the creator, not a confirmed ZimaOS defect.

Once the Hardware Settled Down, the Server Stayed Stable

After reducing the network-card count and removing the problematic hardware combination, sbinske reported that the system ran steadily.

That changed his view of the project. The initial freezes had made the installation look unreliable, but the later behavior suggested a more complicated interaction between the operating system and an unusual collection of reused desktop components.

For a DIY build, that distinction mattered more than identifying a perfect root cause. He had reached a configuration that could keep the LAN-party services running, and two network cards were already enough for the role he had planned.

The App Store Was Where ZimaOS Felt Less Friendly Than Unraid

The strongest usability criticism in sbinske's questionnaire was the App Store experience for third-party Docker containers.

His reference point was Unraid: install an App Store, search for the container, follow a clear description and setup form, then install it. He felt ZimaOS could reach the same result, but that bringing in an unfamiliar or third-party container required too much knowledge for non-professionals and hobbyists.

That feedback was recorded in February 2026. Current ZimaOS documentation now says users can import arbitrary Docker Compose YAML, edit configurations directly, run multi-container stacks, and use community-maintained third-party stores. The developer documentation also describes the current App Store packaging workflow in much more detail.

Those newer capabilities do not erase his original experience. They provide useful context: the workflow he found too complicated was exactly the type of area ZimaOS continued to expand later in 2026.

Storage Flexibility Was the Other Missing Piece

sbinske also wanted more freedom to split several disks into different storage groups for different workloads.

His example was practical: one pair of disks might be used as RAID 0 where capacity and speed matter more than redundancy, while another pair could be RAID 1 for data that deserves mirroring. His SyncServer workload, in particular, needed more than 4TB of space but did not require the same level of data protection as more important storage.

From his perspective, being able to combine cheaper existing disks into workload-specific arrays could lower hardware cost and make better use of the drives already on hand.

Current ZimaOS documentation now covers RAID 0, RAID 1, RAID 5, RAID 6, JBOD, and ZFS. However, the public documentation reviewed for this story does not explicitly confirm the exact multi-array workflow sbinske requested — for example, independently creating a two-disk RAID 0 and a separate two-disk RAID 1 on the same host through the normal UI. For that reason, this page preserves his request instead of claiming it has been fully resolved.

A Non-Professional User's Definition of Success

What makes this project useful is that sbinske did not judge the system by how many advanced features it exposed. He judged it by whether it could support the services he actually wanted to run.

After the hardware troubleshooting, the answer was largely yes. ZimaOS was lighter than Unraid, but that was acceptable because his LAN-party server did not need every Unraid feature. Two Docker containers, three virtual machines, local DNS, voice communication, synchronization, and event-management services were enough to make the server useful.

His criticisms came from the same practical mindset. Easier third-party Docker installation would reduce the learning curve. More flexible disk grouping could reduce hardware cost. Better compatibility with unusual desktop expansion-card combinations would make spare-hardware projects less unpredictable.

The Story Is Still Being Written

sbinske and Zima's story is still being written. His current project started as a lightweight Unraid alternative for a retro LAN party and became a real-world test of how ZimaOS behaves on reused desktop hardware under a mixed Docker-and-VM workload.

The final result was not a perfectly clean first install. It was a working DIY system reached through component-level troubleshooting: remove the GT 710, reduce the expansion-card combination, keep the two NICs that were actually needed, and move forward once the machine stayed stable.

For someone who explicitly describes himself as a hobbyist rather than a professional, that may be the most useful outcome of the project. The system did not hide every technical detail from him, but once the hardware combination was simplified, it delivered the lighter home-server environment he had been looking for.

For current platform context, see the ZimaOS feature overview and the current RAID configuration reference.