• Status: hottest drive, storage per pool and array, fan speeds, and parity state if you have a classic array. The Storage picker chooses whether the page and the main Storage and Overview LCD screens show all storage or one pool. Charts show the last 24 hours of drive temperature, storage and fan speed.
• Fans: fixed speed or a fan curve, per group, on all groups, or for each fan. Groups can follow the motherboard. Curves can follow the hottest drive, the average drive temperature, the hottest drive in one pool, or a hardware temperature sensor. Curve smoothing stops fans hunting around a curve point. Speeds stop at 20%, so fans can't be stopped by accident.
• AIO: this tab appears when an AIO is connected. Set the pump and radiator fans to automatic, a fixed speed or a fan curve, or to follow the motherboard if the AIO supports it. Fixed pump speeds stop at 30%. Curves can follow coolant temperature on AIOs that report it. The pump screen's brightness, theme, rotation, colours and sensors are also here.
• Lights: effect, colours, brightness, speed and direction per fan group, or all at once. Depending on the hardware, set each zone or region separately, colour single LEDs, swap directions, change the LEDs per fan, or follow the motherboard. Presets and Saved setups store lighting under a name. Quick Sync runs one effect across several devices. The OpenRGB server lets OpenRGB control the lights.
• Screens: what each LCD shows: an Unraid screen, your own design, a sensor gauge, your own file or a solid colour, plus brightness, rotation and colours. The Drives, Storage and Overview screens have a Pool choice on each LCD, and new pools appear automatically. System screens show CPU usage, memory usage, a system overview or a temperature sensor, and these gauges change colour at 70 and 85 °C. Per-core, Wi-Fi and extra drive or network readings don't get their own screen, but are in the gauge list. Files can be positioned and zoomed, and videos can set their frame rate. Startup image sets what a screen shows at power-on. Screen designs is the drag-and-drop designer. Template catalog installs ready-made designs from GitHub, and Stored template files clears out leftovers. Upload files here, and start pixel cleaning.
• Auto: schedules (brightness, optional screen swap, optional lights off) and alerts that take over every screen for a hot drive, a disk problem, parity errors, a nearly full pool or hot AIO coolant. Muting lasts 24 hours. Schedules don't change fan speeds.
• System: pair, unpair, take over, identify, rename and restart devices. General settings include the USB backend and a temperature alert on the lights. Restore a backup previews and restores the daemon's own backups. Also here: your password, Installation Health, a diagnostics report, an update check, and the version and credits under About.

An LCD left on Leave as it is is only touched while an alert or a screen-swapping schedule is active, and is restored afterwards.

Settings are stored in extras/settings.json in AppData, chart data in extras/history.json and uploads in extras/media.

One container runs:

• lianli-daemon --system as the lianli user, the same way upstream's lianli-daemon-system.service does. It keeps fan curves, RGB and LCDs running.
• The dashboard on port 6090, plus the Unraid stats and LCD automation (Node, no dependencies).

The image installs the upstream Debian 13 release .deb, checked against the release's SHA256SUMS, so there is no Rust or Node build. The upstream desktop GUI is removed, so there's no X display, VNC or second port.

Layout

Dockerfile                       debian:trixie-slim + upstream .deb
rootfs/usr/local/bin/
  entrypoint.sh                  container setup that systemd/tmpfiles/udev would normally do
  sync-devices.sh                mirrors /dev/bus/usb and /dev/hidraw* from sysfs (udev stand-in)
rootfs/opt/lianli-extras/        dashboard, Unraid stats and LCD automation
rootfs/etc/supervisor/supervisord.conf
tests/                           mock daemon tests and template checks
templates/lian-li-linux.xml      Unraid Docker template
screenshots/                     images for this page and the app listing
ca_profile.xml, icon.*, LICENSE  Community Applications repository files
.github/workflows/docker.yml     builds and pushes to ghcr.io

Build and test

Every push to main builds and pushes ghcr.io/teh1percent/lian-li-linux-unraid:latest and :<version>. To follow a new upstream release, change ARG LIANLI_VERSION in the Dockerfile, or run the workflow by hand with the version as input.

To build on the Unraid server, then set the template's Repository to lian-li-linux-unraid:latest:

docker build -t lian-li-linux-unraid:latest .

To run the tests:

node --test tests/*.test.js

The container check

Upstream's daemon won't start if it detects a generic container. It looks for /.dockerenv, $container or /run/.containerenv, then exits with "Cannot verify host-wide daemon ownership from this container". The check exists because the daemon can't see a host-side daemon that might be driving the same hardware. On Unraid nothing else drives that hardware, so entrypoint.sh removes those markers and the daemon runs in its normal system mode. It still takes its usual ownership lock, inside the container.

The entrypoint also does what the distro packaging normally handles:

• creates /run/lianli-daemon.lock and /run/lianli-control.lock (tmpfiles.d)
• creates /run/lianli for the socket (systemd RuntimeDirectory)
• remaps the lianli user to PUID:PGID and owns /var/lib/lianli (systemd StateDirectory)
• starts sync-devices.sh. Every 3 s it recreates /dev/bus/usb/*/* and /dev/hidraw* from sysfs as root:lianli 0660, which is what upstream's 60-lianli.rules grants. Without it, devices that re-enumerate after the container starts (LCD mode switches, replugged dongles) would be invisible. These nodes live in the container's private /dev, so host permissions don't change.