Hi,

When using a container on RouterOS (7.16.2) with disk nvme, I have a problem with file persistence.
Same non-persistence fault for adlist, whitelist, queries, activity etc.. (error config mount / rights ???)

Example
The container is PiHole, which allows you to define local custom dns.
These are then saved in the /etc/custom.list file.
As long as I don't update (stop/remove/add) the container, everything's fine.
But as soon as I update the default (empty) config, the mounts config is overwritten. Have you ever encountered this problem?

But as soon as I update the default (empty) config, the mounts config is overwritten.

What does this means? Reset Pi-hole to default config with its Teleporter feature or directly on fs? If is that, this is expected, mount just holds files (in this case current Pi-hole config files) which will not be deleted after container is removed and it will be mounted at same path when again adding container if mount is added in container mounts. If you made Pi-hole config changes it would be persisted, mount is not recovery backup/restore in this case.

But as soon as I update the default (empty) config, the mounts config is overwritten.

What does this means? Reset Pi-hole to default config with its Teleporter feature or directly on fs? If is that, this is expected, mount just holds files (in this case current Pi-hole config files) which will not be deleted after container is removed and it will be mounted at same path when again adding container if mount is added in container mounts. If you made Pi-hole config changes it would be persisted, mount is not recovery backup/restore in this case.

This means I lose the configuration after a stop/remove/pull/start when I update the container.
So the configuration present in the nvme disk (mount /nvme1/docker/pihole/etc : /etc/pihole) is overwritten.

This shuld not happen if Pi-hole configuration is not touched before and after creating container. I'm using Pi-hole in ROS container, never had such issues and also having some config in custom.list file. Check FS for errors on Linux, maybe there are some FS issues.

Possibly an issue with the mount location ?

On RB5009 there is a confirmed issue with startup of some USB3 stick so I have to be really careful with my containers too after restart/ reboot.

I've found MY mistake!
It's in the mounting and creation of the container :
And mounts was :
So the mount points were identical to the root dir and were overwritten with every upgrade !

by correcting with a dir configs it works immediately better

Thank you for your feedback, which helped me with the correction.

Good catch !