[Bug]: Extra filesystem ignored as duplicate due to Docker automatic bind mounts

[Rindlavesh]

Welcome!

• I have read the Documentation
• I have checked the Common Issues Guide and my problem was not mentioned there.
• I have searched open and closed issues and my problem was not mentioned before.
• I have verified I am using the latest version available. You can check the latest release here.

Component

Agent

Problem Description

I'm unable to get one of my extra-filesystem disks to display properly. I found some issues that appear to be related to mine, but I think this is different enough to post. I've used AI to summarize my problem below:

When adding a second extra-filesystem with LVM device is the same as the one Docker uses for its automatic system bind mounts (/etc/resolv.conf, /etc/hostname, /etc/hosts), the extra filesystem is silently dropped with "Ignoring duplicate FS" and never appears in the UI.

I'm on a UGREEN DXP4800 Pro running UGOS Pro, /etc/resolv.conf, /etc/hostname, and /etc/hosts are all on the same LVM-on-RAID device as /volume2. Docker automatically bind-mounts these files into every container, so Beszel finds that device via the system files first. When it then processes the explicit /volume2 extra-filesystem entry, it treats it like a duplicate and discards it.

Volume1 works fine because its LVM device is different from the one backing the system files.

Expected Behavior

System bind mounts like /etc/resolv.conf, /etc/hostname, and /etc/hosts should not be considered when deduplicating extra-filesystem entries. Only root and explicitly declared extra-filesystem mounts should participate in duplicate detection.

Steps to Reproduce

1. Have a NAS or server where /etc/resolv.conf, /etc/hostname, and /etc/hosts reside on an LVM-on-RAID volume (e.g. UGREEN DXP4800 Pro with UGOS Pro)
2. Deploy beszel-agent as a Docker container
3. Add that same LVM volume as an extra-filesystem mount in the compose config
4. Start the agent and check logs. The extra filesystem is detected then immediately dropped with Ignoring duplicate FS
5. Volume does not appear in Beszel UI, even though it's being correctly detected

OS / Architecture

linux/amd64 (agent), linux/amd64 (hub)

Beszel version

0.18.6 (also tested on beszel-agent:dev but the issue persists)

Installation method

Docker

Configuration

beszel-agent:
  image: henrygd/beszel-agent
  container_name: Beszel-Agent
  network_mode: host
  volumes:
    - /var/run/docker.sock:/var/run/docker.sock:ro
    - /volume1/docker/beszel-agent:/var/lib/beszel-agent
    - /volume1/.beszel:/extra-filesystems/md1__Volume1:ro
    - /volume2/.beszel:/extra-filesystems/md2__Volume2:ro
  environment:
    LISTEN: 45876
    FILESYSTEM: /dev/sda1

Hub Logs

n/a

Agent Logs

INFO Detected disk name=Volume2 device=/dev/mapper/<lvm-device> mount=/extra-filesystems/md2__Volume2 io=md2 root=false
INFO Ignoring duplicate FS name=md2 mount=/extra-filesystems/md2__Volume2
DEBUG Extra FS data=map[Volume1:0x...]

[henrygd]

Can you post the rest of the disk related debug logs from the agent? I'm not sure I understand your problem. Have you tried specifying FILESYSTEM?

The Ignoring duplicate FS log should only show if the additional device has the exact same usage (total and used) as your root device. Is your goal to explicitly show the same information twice?

[Rindlavesh]

Thanks for the quick response. Yes, FILESYSTEM is already set to /dev/sda1.

I want to monitor two separate volumes. One is called Volume1 (HDD RAID 5 array) and one Volume2 (NVMe RAID 1 array). Volume1 shows up correctly, but Volume2 is always dropped. They're completely different disk arrays with different usage stats, so I'm not trying to show the same info twice.

Here is the full debug output:

2026/04/02 08:24:41 INFO Data directory path=/var/lib/beszel-agent
2026/04/02 08:24:41 DEBUG 0.18.6
2026/04/02 08:24:41 DEBUG Not monitoring ZFS ARC err="open /proc/spl/kstat/zfs/arcstats: no such file or directory"
2026/04/02 08:24:41 DEBUG Disk partitions="[{\"device\":\"overlay\",\"mountpoint\":\"/\",\"fstype\":\"overlay\",\"opts\":[\"rw\",\"relatime\"]} {\"device\":\"proc\",\"mountpoint\":\"/proc\",\"fstype\":\"proc\"} {\"device\":\"tmpfs\",\"mountpoint\":\"/dev\",\"fstype\":\"tmpfs\"} {\"device\":\"devpts\",\"mountpoint\":\"/dev/pts\",\"fstype\":\"devpts\"} {\"device\":\"sysfs\",\"mountpoint\":\"/sys\",\"fstype\":\"sysfs\"} {\"device\":\"cgroup\",\"mountpoint\":\"/sys/fs/cgroup\",\"fstype\":\"cgroup2\"} {\"device\":\"mqueue\",\"mountpoint\":\"/dev/mqueue\",\"fstype\":\"mqueue\"} {\"device\":\"shm\",\"mountpoint\":\"/dev/shm\",\"fstype\":\"tmpfs\"} {\"device\":\"/dev/mapper/<lvm-device-vol1>\",\"mountpoint\":\"/extra-filesystems/md1__Volume1\",\"fstype\":\"btrfs\",\"opts\":[\"ro\",\"relatime\",\"bind\"]} {\"device\":\"/dev/mapper/<lvm-device-vol2>\",\"mountpoint\":\"/extra-filesystems/md2__Volume2\",\"fstype\":\"btrfs\",\"opts\":[\"ro\",\"relatime\",\"bind\"]} {\"device\":\"/dev/mapper/<lvm-device-vol2>\",\"mountpoint\":\"/etc/resolv.conf\",\"fstype\":\"btrfs\",\"opts\":[\"rw\",\"relatime\",\"bind\"]} {\"device\":\"/dev/mapper/<lvm-device-vol2>\",\"mountpoint\":\"/etc/hostname\",\"fstype\":\"btrfs\",\"opts\":[\"rw\",\"relatime\",\"bind\"]} {\"device\":\"/dev/mapper/<lvm-device-vol2>\",\"mountpoint\":\"/etc/hosts\",\"fstype\":\"btrfs\",\"opts\":[\"rw\",\"relatime\",\"bind\"]} {\"device\":\"/docker.sock\",\"mountpoint\":\"/var/run/docker.sock\",\"fstype\":\"tmpfs\"} {\"device\":\"/dev/mapper/<lvm-device-vol1>\",\"mountpoint\":\"/var/lib/beszel-agent\",\"fstype\":\"btrfs\",\"opts\":[\"rw\",\"relatime\",\"bind\"]}]"
2026/04/02 08:24:41 INFO Detected disk name=Volume1 device=/dev/mapper/<lvm-device-vol1> mount=/extra-filesystems/md1__Volume1 io=md1 root=false
2026/04/02 08:24:41 INFO Detected disk name=Volume2 device=/dev/mapper/<lvm-device-vol2> mount=/extra-filesystems/md2__Volume2 io=md2 root=false
2026/04/02 08:24:41 DEBUG /extra-filesystems mountpoint=/extra-filesystems/md1__Volume1
2026/04/02 08:24:41 DEBUG /extra-filesystems mountpoint=/extra-filesystems/md2__Volume2
2026/04/02 08:24:41 INFO Ignoring duplicate FS name=md2 mount=/extra-filesystems/md2__Volume2
2026/04/02 08:24:41 DEBUG Extra FS data=map[Volume1:0x29777a928500]
2026/04/02 08:24:41 DEBUG Stats data="... ExtraFsPct:map[Volume1:14.07] ..."

I appreciate any help you can provide.

[github-actions]

👋 This issue has been automatically marked as stale due to inactivity. If this issue is still relevant, please comment to keep it open. Without activity, it will be closed in 7 days.

[henrygd]

Sorry, I haven't had time to look further into it, but /dev/sda1 is not visible in the container according to the logs, so it won't work as the FILEYSYSTEM value.

Check the DEBUG Disk partitions line and try changing FILEYSTEM to match a mountpoint or device value. If the expected device isn't in the logs, try mounting another folder somewhere in the container.

Edit: Actually you might be using /dev/sda1 strictly to choose the IO device. I searched the logs for that and didn't find it, but it looks like the DEBUG Disk I/O diskstats line in the debug logs was removed. Or didn't output for some reason.

[BootstrapperSBL]

This looks like it might share the registerFilesystemStats dedup path from #1931 — the same LVM device backing both /etc/resolv.conf (Docker's auto bind mount) and /extra-filesystems/md2__Volume2 would collide on the device-derived key, so whichever mount gets scanned first wins and the other is dropped.

My open PR #1932 falls back to a basename-derived key when a different mountpoint hits an already-registered device key. If @henrygd thinks that's the same root cause here, I can extend the test coverage to match this Docker bind-mount setup and confirm.

[henrygd]

@BootstrapperSBL That would be great, thank you. I will look at the PR later today if I have time. We may also want to add the IO device as a property rather than using it as the map key.