[Bug] Container OS reported instead of Host

[dantebarbieri]

Description of the bug

When the Docker Host OS does not store its os-release in a file at /etc/os-release, dash. can fail to resolve it and instead surfaces the container's /etc/os-release. I discovered this using NixOS, which uses an absolute symlink in /etc/os-release which when fully followed yields the os-release in a completely different location.

From man os-release:

/usr/lib/os-release is the recommended place to store OS release information as part of vendor trees. /etc/os-release should be a relative symlink to /usr/lib/os-release, to provide compatibility with applications only looking at /etc/.

My home server runs NixOS which fastfetch displays properly:

But in dash., it shows as Ubuntu 20.04.6 LTS (as I run the :nvidia version, it shows Alpine on :latest):

I expect dash. to recursively resolve the links under /mnt/host until it locates os-release or gives up after a reasonable number of link evaluations. Technically the guidance says:

A relative symlink instead of an absolute symlink is necessary to avoid breaking the link in a chroot or initrd environment.

But dash. can reasonably work around this because the root is at a well-known /mnt/host/ when the dash. docker instructions are followed properly.

How to reproduce

1. Install NixOS and verify that less /etc/os-release shows the system info.
2. Double check that /etc/os-release is a link with ls -l /etc/os-release.
3. Run the latest dash. Docker container following the official guidance. You can also use the :nvidia version.
4. Open dash. and the web view will improperly display the OS.

Theoretically other distros may fail too since the code expects:

const MNT_OS_PATH = '/mnt/host/etc/os-release';

If any distro uses an absolute link (or an absolute link at any point in a chain of multiple links) to the real file, dash. will fail to properly resolve the os-release in Docker since absolute links do not resolve naturally when / is mounted under /mnt/host/.

Relevant log output

% docker compose logs -f dashdot
dashdot  | listening on *:3001
dashdot  | Using default network interface "wlp193s0"
dashdot  | Using host os version from "/etc/os-release" and "/usr/lib/os-release"
dashdot  | Static Server Info: {
dashdot  |   os: {
dashdot  |     arch: 'x64',
dashdot  |     distro: 'Ubuntu',
dashdot  |     kernel: '6.12.39',
dashdot  |     platform: 'linux',
dashdot  |     release: '20.04.6 LTS',
dashdot  |     uptime: 182917.07,
dashdot  |     dash_version: '6.1.0',
dashdot  |     dash_buildhash: 'ee73ec807e04018b3d14f6a915f7cb9311899428'
dashdot  |   },

Info output of dashdot cli

% docker compose exec dashdot yarn cli info
INFO
=========
Yarn: 3.8.7
Node: v20.19.3
Dash: 6.1.0

Cwd: /app
Hash: ee73ec807e04018b3d14f6a915f7cb9311899428
Platform: Linux 9d388e26d93e 6.12.39 #1-NixOS SMP PREEMPT_DYNAMIC Thu Jul 17 16:37:24 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Docker image: nvidia
In Docker: true
In Docker (env): true
In Podman: false

What browsers are you seeing the problem on?

All

Where is your instance running?

Linux Server (via Docker)

Additional context

I have a fix for this (#1233) that introduces the ability for dash. to resolve absolute links within its /mnt/host environment. I have confirmed that it properly resolves within my NixOS environment:

dash-1  | listening on *:3001
dash-1  | Using default network interface "wlp193s0"
dash-1  | Bound "/mnt/host/etc/os-release" → "/mnt/host/nix/store/f74y7ymw3g15zgfnh6k3prfzj0fcjfqg-etc-os-release" to "/etc/os-release" and "/usr/lib/os-release"
dash-1  | Using os-release from "/etc/os-release" or "/usr/lib/os-release"
dash-1  | Static Server Info: {
dash-1  |   os: {
dash-1  |     arch: 'x64',
dash-1  |     distro: 'NixOS',
dash-1  |     kernel: '6.12.39',
dash-1  |     platform: 'linux',
dash-1  |     release: '25.11',
dash-1  |     uptime: 182342.09,
dash-1  |     dash_version: 'unknown',
dash-1  |     dash_buildhash: 'badc6cfd18a6850bde78a9a41afe97e43ad1bff3'
dash-1  |   },

[jabuxas]

am able to reproduce it

[github-actions]

🎉 This issue has been resolved in version 6.2.0

Please check the changelog for more details.

[dantebarbieri]

@MauriceNino Interestingly, my fix does not appear to be complete. I am running 6.2.0 now,

dashdot  | Bound "/mnt/host/etc/os-release" → "/mnt/host/nix/store/23v22xm0akyawan9p3y3nl475kskxly4-etc-os-release" to "/etc/os-release" and "/usr/lib/os-release"
dashdot  | Using os-release from "/etc/os-release" or "/usr/lib/os-release"
dashdot  | Static Server Info: {
dashdot  |   os: {
dashdot  |     arch: 'x64',
dashdot  |     distro: 'Ubuntu',
dashdot  |     kernel: '6.12.41',
dashdot  |     platform: 'linux',
dashdot  |     release: '25.11',
dashdot  |     uptime: 224128.56,
dashdot  |     dash_version: '6.2.0',
dashdot  |     dash_buildhash: '4b754915784c835e5c20e6aeb1c77865d1f7d89c'
dashdot  |   }

But in the container, I see that both /etc/os-release and /usr/lib/os-release are linked to the proper file which contains the proper contents:

root@821a769f6317:/app# ls -l /usr/lib/os-release
lrwxrwxrwx 1 root root 67 Aug 11 13:35 /usr/lib/os-release -> /mnt/host/nix/store/23v22xm0akyawan9p3y3nl475kskxly4-etc-os-release
root@821a769f6317:/app# ls -l /etc/os-release
lrwxrwxrwx 1 root root 67 Aug 11 13:35 /etc/os-release -> /mnt/host/nix/store/23v22xm0akyawan9p3y3nl475kskxly4-etc-os-release
root@821a769f6317:/app# more /usr/lib/os-release
ANSI_COLOR="0;38;2;126;186;228"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="25.11pre840654.c2ae88e026f9"
CPE_NAME="cpe:/o:nixos:nixos:25.11"
DEFAULT_HOSTNAME=nixos
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
ID_LIKE=""
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 25.11 (Xantusia)"
SUPPORT_URL="https://nixos.org/community.html"
VARIANT=""
VARIANT_ID=""
VENDOR_NAME=NixOS
VENDOR_URL="https://nixos.org/"
VERSION="25.11 (Xantusia)"
VERSION_CODENAME=xantusia
VERSION_ID="25.11"
root@821a769f6317:/app# more /etc/os-release
ANSI_COLOR="0;38;2;126;186;228"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="25.11pre840654.c2ae88e026f9"
CPE_NAME="cpe:/o:nixos:nixos:25.11"
DEFAULT_HOSTNAME=nixos
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
ID_LIKE=""
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 25.11 (Xantusia)"
SUPPORT_URL="https://nixos.org/community.html"
VARIANT=""
VARIANT_ID=""
VENDOR_NAME=NixOS
VENDOR_URL="https://nixos.org/"
VERSION="25.11 (Xantusia)"
VERSION_CODENAME=xantusia
VERSION_ID="25.11"

I did what I should have done from the beginning and looked into the source for the systeminfo NPM package you are using. This is the relevant line:

exec('cat /etc/*-release; cat /usr/lib/os-release; cat /etc/openwrt_release', function (error, stdout) {

cat /etc/*-release; cat /usr/lib/os-release; cat /etc/openwrt_release

I can see in the Docker container that these are the files:

root@821a769f6317:/app# ls -l /etc/*-release
-rw-r--r-- 1 root root 104 Jan  2  2024 /etc/lsb-release
lrwxrwxrwx 1 root root  67 Aug 11 13:35 /etc/os-release -> /mnt/host/nix/store/23v22xm0akyawan9p3y3nl475kskxly4-etc-os-release
root@821a769f6317:/app# ls -l /usr/lib/os-release
lrwxrwxrwx 1 root root 67 Aug 11 13:35 /usr/lib/os-release -> /mnt/host/nix/store/23v22xm0akyawan9p3y3nl475kskxly4-etc-os-release
root@821a769f6317:/app# ls -l /etc/openwrt_release
ls: cannot access '/etc/openwrt_release': No such file or directory

root@821a769f6317:/app# cat /etc/*-release; cat /usr/lib/os-release; cat /etc/openwrt_release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"
ANSI_COLOR="0;38;2;126;186;228"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="25.11pre840654.c2ae88e026f9"
CPE_NAME="cpe:/o:nixos:nixos:25.11"
DEFAULT_HOSTNAME=nixos
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
ID_LIKE=""
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 25.11 (Xantusia)"
SUPPORT_URL="https://nixos.org/community.html"
VARIANT=""
VARIANT_ID=""
VENDOR_NAME=NixOS
VENDOR_URL="https://nixos.org/"
VERSION="25.11 (Xantusia)"
VERSION_CODENAME=xantusia
VERSION_ID="25.11"
ANSI_COLOR="0;38;2;126;186;228"
BUG_REPORT_URL="https://github.com/NixOS/nixpkgs/issues"
BUILD_ID="25.11pre840654.c2ae88e026f9"
CPE_NAME="cpe:/o:nixos:nixos:25.11"
DEFAULT_HOSTNAME=nixos
DOCUMENTATION_URL="https://nixos.org/learn.html"
HOME_URL="https://nixos.org/"
ID=nixos
ID_LIKE=""
IMAGE_ID=""
IMAGE_VERSION=""
LOGO="nix-snowflake"
NAME=NixOS
PRETTY_NAME="NixOS 25.11 (Xantusia)"
SUPPORT_URL="https://nixos.org/community.html"
VARIANT=""
VARIANT_ID=""
VENDOR_NAME=NixOS
VENDOR_URL="https://nixos.org/"
VERSION="25.11 (Xantusia)"
VERSION_CODENAME=xantusia
VERSION_ID="25.11"
cat: /etc/openwrt_release: No such file or directory

The problem is the /etc/lsb-release file from Linux Standard Base:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"

From man lsb_release:

If the installation is LSB compliant, the "/etc/lsb-release" file should contain the LSB_VERSION field. The value of the field should be a colon separated list of supported module versions indicating the LSB specification modules to which the installation is compliant. If the installation is not compliant, the above field should not be present.

Optional fields are DISTRIB_ID, DISTRIB_RELEASE, DISTRIB_CODENAME, DISTRIB_DESCRIPTION and can be used to override information which is parsed from the "/etc/distrib-release" file.

As we can see, the Ubuntu image uses all of those optional fields to override the /etc/os-release file. And the systeminfo code does read these values first, falling back on the NAME key if they are not set.

I think the easiest solution here is to try to grab the /etc/lsb-release (and optionally also /etc/openwrt_release) from the host and overwrite the file in the container. If there is no file for the host, then it seems safest to clear the file(s) from the container to avoid incorrect values being displayed. Do we want to reopen this issue or should I file a new issue for the scenario I described?

[MauriceNino]

Hey, thanks for the info - I have reopened the issue. Can you by any chance provide a PR for this again, please? It seems to work on the public demo, and I don't fully understand what the issue is.

[dantebarbieri]

@MauriceNino sorry it took me a while to get to this. I needed to wait until the weekend to get some time to make progress. The fix is in #1271.

For clarity, the problem was that the :nvidia container (based upon Ubuntu) had a file, /etc/lsb-release which was overriding fields in /etc/os-release. This is intentional behavior, and systeminfo handles it properly by ignoring the fields in /etc/os-release, but this means that the OS is still reported as Ubuntu when I am on NixOS since the /etc/lsb-release was not linked to the file on the host (if it exists) or deleted (if no such host file exists at the end of /mnt/host/etc/lsb-release).

The logging for which file was linked where was also not ideal, so I improved that too.