I am experiencing a persistent issue when trying to run an Uptime Kuma container on my RB5009 running RouterOS 7.22.1 (ARM64).
I'll start by saying that I know RouterOS quite well, but I'm new to the container world.
I initially installed the container using the internal flash memory for both root-dir and mountlists. The installation went perfectly on the first shot, and the application was fully functional.
To prevent internal flash wear, I removed the container and decided to reinstall it using an external USB drive (/usb1), which is formatted in EXT4. I set the root-dir to the USB and created a mount point for /app/data pointing to a folder on /usb1.
When launching the container from the USB drive, it enters a crash loop and fails immediately during the entrypoint execution. Here is the relevant log snippet:
== Performing startup jobs and maintenance tasks
chown: changing ownership of '/app/data': Operation not permitted
*** error: exited with status 1
What I have already tried:
I added UPTIME_KUMA_ENABLE_CHOWN=0 to the container's env list to bypass the internal chown script, but the container still attempts the operation or fails right after.
I tried forcing the container to run as root by setting user=0 in the RouterOS container settings, but the Operation not permitted error on the /app/data mount point persists.
Has anyone found a clean workaround to host Uptime Kuma on USB storage?
Ext4, like (say) ext2, ext3 (and also on Windows NTFS) are filesystems where files or paths/diirectories can have ownership and/or permissions.
Other filesystems like (still say) FAT12/16/32 and exFAT are filesystems where files or paths/directories have not permissions or ownership.
Since it is not clear (to me) if your chown issue is related to the filesystem used, I suggested to try with another (or the same, re-formatted) USB stick using FAT32 filesystem and see what happens.
On USB drive container root-dir is created and on same USB root dir (/usb1 is USB root when mounted on ROS) is mounted into container /app/data dir? If that is true, then this is causing issue, mount some directory (not USB root and which is not inside container root-dir) on USB drive (doesn’t need to be created it will be created on first container start).
Maybe not applicable right here but also be aware there is a well-known nasty bug on RB5009 where for some USB3 devices, it fails to recognize them as such on reboot.
And then your complete USB file structure is toast ... /usb1 becomes /usb2 and then the fun starts.
On the next reboot, it may be correct again. Or not.
A USB reset with some delay should help before launching anything which should run on that USB part.