Dear members of the Mikrotik forum,

I am seeking assistance with an issue I am having with my Mikrotik router and the Uptime Kuma Docker. Specifically, I am not having difficulty getting the Docker to run properly on my router and would appreciate any help or guidance that the community could offer.

I have tried using Pihole on my router and it is working without any issues, but I am unable to get Uptime Kuma to work in the same way.
Any help or suggestions on how to resolve this issue would be greatly appreciated. Thank you in advance for your assistance.

Sincerely,

Thanks, i just tried, and yes, there is small bug that would not allow to start this unless you do few extra steps (fix will be available soon)

Setup container setup as explained in our help page (add registry url, add installation medium, set tmpdir if not enough memory on main disk)

setup mounts: add container: On first start it may fail due to permission error, to fix this delete hidden file in configuration folder.
Connect to router using sftp, scp, ftp. delete hidden file in config folder - disk1/kuma_data/.type
for example if using sftp it would look like this: Kuma will now run on RouterOS.
map ports as per container help page example.

Thanks for the help worked 100%

Followed the same steps and when I press run, the container says running and then stopped a few seconds later.

When I go to take a look for the .type it is not there.

I am trying to run on a RB3011UiAS running v7.6 , I have pihole working fine with no issues

The file type is hidden that's why you might have some hard time finding it depending on what rstp client you're using

The real solution is to fix this "bug" inside the container since it's doing something wrong in the entrypoint.sh script.
I have a fix for that and will submit a PR to the uptime-kuma git repo which if will be accepted will reduce this unnecessary step.
...
at:
https://github.com/louislam/uptime-kuma/pull/2587

Currently the next container:
https://hub.docker.com/r/elicro/uptime-kuma

works with the fix in case someone wants to use it out of the shelf.

@elico
.type file inside mounts is for RouterOS to mark folder contents as not to be listed inside RouterOS.
Correct fix would be not changing permissions for this file from uptime-kuma side, or allowing permission change or change the way of listing/not listing folders from RouterOS side.
Deleting file form container or RouterOS side is just a workaround.

chown -R will try to change permissions to hidden files, please consider skipping permission change on hidden files or .type file in particularly, that would make a "fix" from uptime-kuma side

@elico
.type file inside mounts is for RouterOS to mark folder contents as not to be listed inside RouterOS.
Correct fix would be not changing permissions for this file from uptime-kuma side, or allowing permission change or change the way of listing/not listing folders from RouterOS side.
Deleting file form container or RouterOS side is just a workaround.

chown -R will try to change permissions to hidden files, please consider skipping permission change on hidden files or .type file in particularly, that would make a "fix" from uptime-kuma side

@antonsb

I understand what you are saying and I can indeed write a find command that will do just that but the basic issue is that the chown shouldn't return a permission denied unless there is a real reason for that.
The RouterOS should have access to the .type file no matter what permission it has so the main issue is that it's being used and forced on the container.
The container assumes that it has control on this volume(mount) which apparently it really doesn't.
I offered a simplified solution but instead why don't you offer a better solution?

A hint... there are two "files" format in the /app/data structure.
These which are meant for the DB with the pattern "kuma*" and the folder "upload/*".
A PR to the uptime kuma project is more then welcome from the RouterOS dev team project developers.

fix for .type will be available in next releases.

fix for .type will be available in next releases.

Thanks!
Looking forward for this.

For now I have provided a better entrypoint.sh version which uses find instead of chown -R and excludes the .type file.
Can be seen at:
https://github.com/louislam/uptime-kuma ... 4499f70f86

Hi antons

Thanks so much for the workaround, I actually jumped the gun and created a video on the subject and creation of this container. Quick note when upgrading from 7.7rc4 to 7.7stable all the files in the kuma_data folder gave permissions errors so I could not start the container any longer. Had to delete all the files to get the container back up and working. Works fine even with reboot afterwards, but meant having to reconfigure Kuma from scratch. Something to take note of for the next build?

@elico
looks much better, newer versions (7.8 brach) will allow to change .type permissions without extra steps.

@TheNetworkBerg
Thanks for your videos! I will try to repeat upgrade issue.

@TheNetworkBerg Did you tried to make a backup using lftp before erasing the mount point?
I will try to test it later on when possible.

...
I have now verified that after the upgrade from 7.6 to 7.7 the old files get the uid and gid of: 65534 and there for cannot be touched even when I am the root user inside the container.
I can delete or rename the files but cannot change their ownership.

and it's the same if I am backing up a file via lftp and back, the same uid and gid.
It's also the same when I am uploading the files via the winbox into the folder when the .type file was deleted.

I hope that in 7.8 it will be fixed.
...
I managed to restore the data using a second mount and the install/cat command.
I added a new mount for the /app/data dir and the old mount I have mounted under /data.
Then I started the container which started fine but with a new DB.
Then I entered the shell and went into /data which I cannot change ownership but can read/remove/move the files.
I then created a tmp dir and moved all the files into the tmp directory.
Then one by one what I did was to run the next command:

install -C -m 664 -o root -g root /data/tmp/kuma.db /data/kuma.db
...
mkdir /data/upload

and then stopped the container and mounted the old mount into /app/data.
Then it worked as expected and with the old data.

I have seen two issues:
First is that I cannot really backup the containers and then restore them unless I have this specific function in the container itself.
Second is that a root user cannot do many things as it should.

we would need step by step how this can be repeated.
For me files always stay with correct uid,gid when upgrading from 7.6 to 7.7

we would need step by step how this can be repeated.
For me files always stay with correct uid,gid when upgrading from 7.6 to 7.7

I will try to test it later on.
I have tested this on HAP AC3, every file I am uploading via lftp or winbox has a the above 65534 UID and GID.
I will verify if it's my doing that it has changed the uid and gid with a CHR trial VM later on.

By the way, thanks for all the efforts.

I mentioned this elsewhere, but there also needs to be a way to migrate files from one SSD to another and maintain permissions. I used scp to copy files from one router to another, but after installing the larger SSD with the copied files, the container doesn't have permissions to read them. Using ROS's SMB, I was also able to copy and move things around on the disk, but with the same permissions problems.

I'm hoping to leverage a trick like elico to avoid having to rebuild my container (in this case, Pi Hole).

Edit: I used lftp to copy files into a mount that was available to the running container (Pi Hole's /etc/pihole mount). The container could read those, but not write/change them, so I arranged them in a different directory such that I could remove the unchangeable files using lftp, then copied them into place within the container. A little hokey, but it worked.