Do I need to use privileged mode and pass /dev to have disks automatically detected and monitored?

[sofakng]

I’d like to have my disks (20+) automatically detected and monitored but I don’t want to have to change the docker-compose.yaml or collector.yaml every time I replace a disk, etc.

Does that mean I need to use privileged: true and volumes: - /dev:/dev:ro ?

[Starosdev]

Short answer: Yes, privileged: true + -v /dev:/dev:ro is the right approach for your use case.

How it works under the hood:

The collector always runs smartctl --scan automatically on each collection run — no collector.yaml configuration is needed for standard disks. The issue is purely whether the container can see the /dev nodes in the first place.

Option A — Explicit device list (default, more secure):

devices:
  - "/dev/sda"
  - "/dev/sdb"
  # ... repeat for all 20+
cap_add:
  - SYS_RAWIO
  - SYS_ADMIN  # required for NVMe
volumes:
  - /run/udev:/run/udev:ro

smartctl --scan runs inside the container and only sees what you explicitly passed in. Secure, but you have to update the list when disks change.

Option B — Privileged + full /dev mount (zero maintenance):

privileged: true
volumes:
  - /dev:/dev
  - /run/udev:/run/udev:ro

smartctl --scan behaves as if it is running directly on the host — it sees all current disks and auto-detects new ones without any config changes. This is the intended workaround for large or frequently-changing disk sets. Note that --privileged gives the container full host access, so it is a security tradeoff.

Note on /run/udev:/run/udev:ro: This is separate from device detection — it is used to enrich device metadata (filesystem labels, UUIDs). It should be included regardless of which option you choose.

[sofakng]

Thanks so much for the reply! I can add :ro to the /dev passthrough for extra security though, right?

[Starosdev]

Unfortunately no -- smartctl needs write access to device nodes to send ioctl commands, even though it is not writing to your disks. Mounting /dev:/dev:ro will cause permission errors.

Also, when privileged: true is set, :ro does not add meaningful security anyway -- a privileged container can remount it read-write. The real security tradeoff is privileged itself, not the mount flag.