It is confusing initially.
The /container/mount "src" is the RouterOS directory, so that can be anything, with any levels of nesting desired. I don't use PiHole but given the above, but I do something like this:
SRC -> DST
In the /container root-dir=, I'd personally use the same parent directory as mounts, but call it root
Now the /container work-dir= you should leave BLANK when creating a container, unless some very specific instruction suggest you need to set it. The Dockerfile uses to build the image specifies this, so RouterOS will "inherit" it. So changing it actually risk breaking things. Once a container is started the working dir set then set from Dockerfile and show in /container. And this really only effects what what directory, inside the container's file system (not RouterOS disk), is used when the "entrypoint=" value appended with "cmd=" is run at /container/start – that is done while shell is cd to work-dir=
While in theory you could not use any mounts, and just use /terminal/shell to edit files on the virtual root disk (i.e. inside the "image" stored at root-dir=)... That may have side-effects down the road when you upgrade, and why the mounts are limited to stuff that you might want to save in upgrade, than say the entire /etc directory. That's why docker, and thus /container, does it this way. But you can organize the RouterOS disk however you like by adjusting paths.
Also, there is one more directory (well two) in /container/config (the "Config" button in winbox on main /container dialog).
/container/config's tmpdir= is what's used to store the download from DockerHub (or any registry configured in that same dialog)... But by default is RouterOS's / root directory & this can be probablatic since it often the flash disk. So tmpdir= should be always be set to a "real" disk (even if USB stick), just not router's internal flash.
Finally, in all this paths it shows "disk1", which is what docs suggest. But importantly your disk's path may be named differently. Often they are now "sata1" or "usb1-part1", not plain "disk1". You can check with "/disk/print" (or System > Disk in winbox) and the slot= name is the path for /container stuff. This one is sneaky since a container may be small enough to fit on the internal flash, but you may have a USB disk or something & so you may run into disk space problems later to then notice nothing was using the USB/etc drive.
The /container/mount "src" is the RouterOS directory, so that can be anything, with any levels of nesting desired. I don't use PiHole but given the above, but I do something like this:
SRC -> DST
/disk1/pihole/etc/pihole -> /etc/pihole
/disk1/pihole/etc/dnsmasq -> /etc/dnsmasq.d
In the /container root-dir=, I'd personally use the same parent directory as mounts, but call it root
Note:that root-dir= does NOT start with a / (at least all versions to date), so unlike mounts do NOT use any starting / in the root dir.root-dir=disk1/pihole/root
Now the /container work-dir= you should leave BLANK when creating a container, unless some very specific instruction suggest you need to set it. The Dockerfile uses to build the image specifies this, so RouterOS will "inherit" it. So changing it actually risk breaking things. Once a container is started the working dir set then set from Dockerfile and show in /container. And this really only effects what what directory, inside the container's file system (not RouterOS disk), is used when the "entrypoint=" value appended with "cmd=" is run at /container/start – that is done while shell is cd to work-dir=
While in theory you could not use any mounts, and just use /terminal/shell to edit files on the virtual root disk (i.e. inside the "image" stored at root-dir=)... That may have side-effects down the road when you upgrade, and why the mounts are limited to stuff that you might want to save in upgrade, than say the entire /etc directory. That's why docker, and thus /container, does it this way. But you can organize the RouterOS disk however you like by adjusting paths.
Also, there is one more directory (well two) in /container/config (the "Config" button in winbox on main /container dialog).
/container/config's tmpdir= is what's used to store the download from DockerHub (or any registry configured in that same dialog)... But by default is RouterOS's / root directory & this can be probablatic since it often the flash disk. So tmpdir= should be always be set to a "real" disk (even if USB stick), just not router's internal flash.
There is also a layer-dir= but you should likely leave that default (empty) unless you run into problems extracting images./container/config set tmpdir=disk1/container/pulls
Finally, in all this paths it shows "disk1", which is what docs suggest. But importantly your disk's path may be named differently. Often they are now "sata1" or "usb1-part1", not plain "disk1". You can check with "/disk/print" (or System > Disk in winbox) and the slot= name is the path for /container stuff. This one is sneaky since a container may be small enough to fit on the internal flash, but you may have a USB disk or something & so you may run into disk space problems later to then notice nothing was using the USB/etc drive.
Statistics: Posted by Amm0 — Tue Jan 28, 2025 6:07 am