You plug in a new ZimaBoard 2, the LED comes on, and you’re left with a small aluminium box and no obvious next step. It has no setup wizard on a screen and no app you have to install first. ZimaOS is already on the eMMC, and it wants you to find it from a browser. This ZimaBoard 2 setup guide covers everything from that first power-on to a fully updated board you can reach over SSH, with a screenshot of every screen along the way.
We cover the first boot, the local account, the ZimaOS update (ours shipped with a year-old image, nine releases behind), the Device info panel, turning on SSH from Developer mode, pinning a static IP, and a quick hardware check from the shell. At the end is a list of what ZimaOS listens on straight after setup, because that surprised us more than anything else. If you haven’t bought one yet and are weighing it against a mini PC, our homelab mini PC picks cover the N100 and N150 boxes it competes with.
What you need before the first boot
The board-only box already includes the 12V/5A power adapter, a SATA Y-cable and a clip-on cooling fan. On top of that you need an Ethernet cable into a switch or router that hands out DHCP leases (step 1 covers a network without one), and a laptop on the same LAN. The ZimaBoard 2 has no built-in Wi-Fi, so the first boot has to be wired. A monitor is optional, but worth it if you have a Mini DisplayPort cable (IceWhale sells a Mini DP to HDMI one), because the console prints the board’s IP for you.
Leave the drives out for now. The 2-Bay HDD Rack Tray is a separate purchase from the ZimaBoard 2 itself, and ZimaOS runs entirely from the internal 32 GB eMMC. Adding disks later is a separate job and doesn’t change anything here. If you already know two drives won’t be enough, IceWhale’s ZimaCube 2 ships ZimaOS too, with six SATA bays and four more M.2 slots in a seventh bay.
1. Power on and find the ZimaBoard 2 IP address
Connect Ethernet to one of the two 2.5GbE ports first, then plug in power. The board starts booting as soon as power is connected. With a monitor attached, the ZimaOS console ends on a status screen that shows the web UI address, the kernel and the ZimaOS build:

Two lines on that screen are worth reading. It says SSH is disabled by default and has to be enabled from the web UI (step 6). It also says root login over SSH needs a root password, which you set by pressing Alt+F2 at this console and running passwd. Without a monitor, look for a new DHCP lease named ZimaBoard2 in your router’s client list, which is the hostname our board reported.
The board shows the address as plain HTTP on port 80. Your router picks this address, so yours will almost certainly differ from ours. Ours was 192.168.1.177, and wherever that address appears below, use the one your board showed instead. Reserve it in your router now, because a DHCP address that changes after a power cut is the most common reason a ZimaOS box suddenly “disappears”. If you would rather pin the address on the board itself, step 7 covers that.
On a network with no DHCP server, such as a cable straight to a laptop or a lab switch with no router behind it, ZimaOS gets no address and there is nothing to browse to. The ports are managed by NetworkManager, so you can give the board a static address from the console instead. This follows IceWhale’s documented method. Press Alt+F2 to switch to a console (log in as root if it asks), then list the connections to find the name of the port your cable is in:
nmcli connection show
Depending on the build, the wired profiles are named “Wired connection 1” and “Wired connection 2” or after the interface (eth0, eth1), so use the name from the NAME column. Switch the one with the cable to a manual address, using an address, gateway and DNS server that fit your network, then bring it back up:
nmcli connection modify "Wired connection 1" ipv4.method manual ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 ipv4.dns 192.168.1.1
nmcli connection up "Wired connection 1"
Give your laptop an address on the same subnet and browse to the board’s new address. Once you’re logged in, set the same address in Settings > Network so it survives the ZimaOS update in step 4, which can replace the whole OS image: pick the port, switch it from DHCP to Manual and save. If the new address is on a different subnet, the dashboard session drops and you reconnect at the new address. IceWhale’s ZimaOS network configuration docs walk through that screen.
2. Create the ZimaOS local account
Browse to the address your board showed in step 1 (http://192.168.1.177 on ours). The first screen asks for a language and for you to accept IceWhale’s privacy policy. The policy checkbox is ticked by default, so read the policy before you click the arrow if that matters to you.

Next comes the account. It’s a local account, not an IceWhale cloud login, and the same credentials later work for SSH and Samba. Pick a strong password here and not a throwaway, because this one password ends up guarding the web UI, the file shares and the shell.

ZimaOS then shows a four-card tour: combine drives into RAID 0/1/5, manage files, remote access through the Zima Client, and the App Store. “Start from Files” and “Start from App Store” jump straight into those apps. Click Dashboard instead, since the update comes first.

3. Read the dashboard numbers
The dashboard is the first proof the board is healthy. The System widget on our unit read 2.2 W and 39°C at 2% CPU, with 7.51 GB of RAM visible. The Storage widget shows only 17.5 GB total, although the eMMC is sold as 32 GB. Some of the gap is GB versus GiB and filesystem overhead, and the rest goes to ZimaOS’s own system partitions, since it updates through A/B system slots. Plan to put apps and data on real drives.

The default apps are App Store, Files, Backup, ZVM (the built-in VM manager), PeerDrop, Settings and a link to the IceWhale community. The red dot on the gear icon at the top left is the one to follow next.
4. Update ZimaOS to the latest release
Our board shipped on a ZimaOS build from September 2025, nine releases behind the current stable one. Open Settings and the General page shows the version, a Plus badge, and an Update available button. The Plus badge is the ZimaOS+ licence that comes with IceWhale hardware, so there’s nothing to buy.

The Update entry downloads the release and then shows its notes. Read the first line before anything else. The notes for the current release lead with a fix for “a high-risk security issue in file services”, and file services are exactly what a NAS exposes. That line alone is reason enough not to leave a new board on the factory image while you try out the App Store.

Click Update. ZimaOS writes the new image to the inactive system slot (it uses RAUC for A/B updates), then reboots into it. The old slot stays intact, which is the point of the A/B design: a bad update has something to fall back to. The progress screen counts up to 100% and then restarts the board:

From clicking Update to the login page coming back took about two minutes on our gigabit connection. The update also moves the board to a newer LTS kernel series. If the browser shows a blank white page instead of the login form, the problem is your browser cache, not the update. The fix is in the troubleshooting section at the end.
After logging back in, the dashboard looks the same, and on our board Storage used dropped from 4.32 GB to 2.89 GB:

Leave “Join the Beta experience” off in Developer mode (step 6) unless you want beta builds. A beta of the next release was already out when we tested, and you don’t want a storage OS tracking the beta channel by accident.
5. Check the hardware in Device info
Under Settings, then General, the Device info button shows the serial number (SN), a device code (DC), CPU, RAM and GPU. We blacked out our SN and DC. Keep yours out of forum posts too, since they identify your specific unit.

The RAM line says “6400 MHz LPDDR5”, while IceWhale’s shop page lists the memory at 4800 MT/s. The shop page is right about what the board runs at. Step 8 shows where the 6400 comes from: it’s the rated speed of the Samsung chips, while the firmware runs them at 4800 MT/s. IceWhale lists a fix for this Device info readout in the ZimaOS release notes for the current beta. Intel rates the N150’s single-channel memory controller at LPDDR5-4800, so the chips run below their rating. The memory is soldered on, so the 8 GB on the 832 model is all you’ll ever have. Pick the 1664 model if you think you’ll run several VMs.
6. Enable SSH on ZimaOS (Developer mode)
SSH is off until you switch it on. Scroll to the bottom of Settings, then General, and open Developer mode. This page also holds the beta toggle, HTTPS for the web UI, DLNA, and the Samba switches. Samba is already on at this point:

Flip SSH Access on. A “Web-based terminal” link appears right under it. The web terminal is ttyd listening on port 7681, served over HTTP on our board. It asks for the same ZimaOS login, so it’s not an open shell, but it is one more listener on the LAN that you never asked for.

While you’re here, leave “Supports Samba1” off. The UI itself calls SMB1 low security, and only an old scanner or media player that can’t speak SMB2 would need it.
7. Set a static IP address on the ZimaBoard 2
A DHCP reservation on the router keeps the address stable, but it lives on the router, not the board. Move the ZimaBoard 2 to another network or replace the router and the reservation is gone. To make the address part of the board’s own config, open Settings > Network in ZimaOS, pick the port and switch Configure IPv4 from DHCP to Manual. The fields come pre-filled from the current lease, so usually only the address needs changing before you save. Now that SSH is on from step 6, you can do the same job with nmcli from the shell instead. Our ZimaOS static IP guide walks through both methods with screenshots, shows why the Network page can keep showing the old address after you save, and covers rolling back to DHCP if the board drops off the network.
8. SSH into the ZimaBoard 2 and verify the hardware
Set your board’s address from step 1 and the account name you created in step 2 once, so the commands below copy cleanly (ours was cfgadmin):
export ZIMA_IP=192.168.1.177
export ZIMA_USER=cfgadmin
Log in and accept the host key on the first connection:
ssh ${ZIMA_USER}@${ZIMA_IP}
Check which groups the account belongs to:
id
The account sits in wheel, so sudo works with your ZimaOS password. It’s also in a samba group, which is how the same login reaches the file shares:
uid=999(cfgadmin) gid=1000(samba) groups=1000(samba),10(wheel)
Confirm the network chips. The ZimaBoard 2 uses Intel’s I226-V, which runs on the in-kernel Intel igc driver that Linux and FreeBSD both ship:
lspci -nn | grep -i ethernet
Both ports show up as revision 04 of the I226-V:
01:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
02:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller I226-V [8086:125c] (rev 04)
Now the driver and NVM firmware. We were plugged into eth0; use eth1 if ip -br link shows the other port as UP:
ethtool -i eth0 | grep -E 'driver|firmware|bus-info'
It’s the in-kernel igc driver. Note the firmware version. If you later see the link drop under load, the I226 NIC drop fixes start from exactly these details:
driver: igc
firmware-version: 2017:888d
bus-info: 0000:01:00.0
The memory check settles the 6400 against 4800 question from step 5:
sudo dmidecode -t memory | grep -E 'Type: LPDDR|Speed:|Manufacturer:' | head -4
The first of the four 2 GiB Samsung packages is shown here, and all four report the same rated 6400 MT/s and configured 4800 MT/s:
Type: LPDDR5
Speed: 6400 MT/s
Manufacturer: Samsung
Configured Memory Speed: 4800 MT/s
Last, the temperatures at idle, with the fan not fitted:
sensors | grep -E 'Package|Core'
The package sat at 41°C in open air on a desk. Our review covers what happens under sustained load with and without the fan:
Package id 0: +41.0 C (high = +105.0 C, crit = +105.0 C)
Core 0: +38.0 C (high = +105.0 C, crit = +105.0 C)
Core 1: +38.0 C (high = +105.0 C, crit = +105.0 C)
Core 2: +38.0 C (high = +105.0 C, crit = +105.0 C)
Core 3: +38.0 C (high = +105.0 C, crit = +105.0 C)
ZimaOS also includes docker, fio, iperf3, smartctl and lspci, so you can benchmark and check drives without installing anything. For anything else, run it as a container, which also keeps it out of the way of the next system update. To install, update and remove those containers from the shell instead of the dashboard, use casaos-cli; our casaos-cli cheat sheet was tested on this board and lists which commands work on ZimaOS.
What ZimaOS listens on after setup
With SSH enabled and no apps installed, this is every listening service we found on the board. It’s useful to know before you forward a port or put the board on a network you don’t fully trust:
| Port | Process | What it is |
|---|---|---|
| 80 | zimaos-gateway | Web UI (plain HTTP unless you enable HTTPS in Developer mode) |
| 22 | sshd | SSH, only after step 6 |
| 7681 | ttyd | Web-based terminal, appears with SSH, password-gated |
| 139, 445 | smbd | Samba file sharing, on by default |
| 3702, 5355 | wsdd2 | Windows network discovery |
| 1910 | ssdpd | SSDP/UPnP discovery |
| 9527 | zimaos | ZimaOS backend service |
| 9993 | zerotier-one | ZeroTier, used by Remote Access |
The ZeroTier line deserves a closer look. Before we touched Remote Access, the board was already a member of a ZeroTier network named “IceWhale-RemoteAccess”, with a virtual interface at 10.147.13.1. Onboarding never asked about it. That network isn’t shared with other IceWhale customers. The first ten hex digits of its ID match the board’s own ZeroTier address, and the controller API on port 9993 shows the board hosting the network itself, with a single member. The catch is that the network is set to public, and on a public ZeroTier network members don’t have to be approved one by one, so the 16-character Remote ID shown under Settings, Network is the thing standing between a stranger and the board’s own SSH, Samba and web UI. ZimaOS warns you to keep it confidential for that reason. If you don’t use the Zima Client, switch Remote access off on that same page. In our test that stopped zerotier-one and removed the virtual interface. A second IceWhale service, znet, owns the tun0 interface at 10.126.126.1. Samba, wsdd2 and SSDP being on by default is typical for a home NAS OS, and Samba can be turned off in Developer mode if you only use the board for Docker apps.
If you’d rather run a similar app dashboard on hardware you already own, ZimaOS grew out of CasaOS, and our CasaOS on Debian guide gets you close on any old x86 box.
Two problems we hit during setup
Blank white page after the ZimaOS update
After the update rebooted, reloading the tab showed an empty page with no login form. The browser console showed the cause: the cached index page from the old version was asking for a Login-*.js file that no longer exists on the board, and it got a 404. The board was fine. A hard refresh (Ctrl+Shift+R, or Cmd+Shift+R on macOS) or clearing the site data for the board’s IP loads the new version straight away. This is the most likely “the update broke my ZimaBoard” moment, and it’s only the browser cache.
SSH refuses the first connection right after enabling it
Our first SSH attempt, made within seconds of flipping the toggle, failed, most likely because sshd was still coming up. A few seconds later the same command connected. If a retry still doesn’t connect, check you’re using the ZimaOS account name and not root: root has no password until you set one at the console with Alt+F2 and passwd, as the boot screen says.
With the board updated and reachable over SSH, the next job is storage. For a two-drive build, get CMR drives, not SMR (our CMR vs SMR breakdown explains why), and look at the NAS hard drives we recommend. A small UPS also saves a lot of RAID resyncs after power cuts, and the homelab UPS roundup covers the sizes that suit a low-power board.