[BUG] Reloading cache removes "www-data" ownership

[TSmigielski]

Bug description

After upgrading to the new version available on docker "2.0.10", I was getting the 500 http code. It took me about 2/3 hours to figure out that: Reloading the cache changes both the owner and group to root, and resets the permissions of the "kimai/var/cache/pro_" and "kimai/var/cache/prod" directories.

As a one time deal, this wouldn't be that bad, to simply write 3 commands in the container to fix this, these 3 for context:

chown -R :www-data
chmod -R g+r
chmod -R g+rw var/

But it will get annoying with every server restart, which happens for me roughly twice per month for various reasons. Of course this is a problem because Kimai reloads the cache on startup, and docker doesn't hold the state of a container when shutting down.

Desktop (please complete the following information):

• OS: Fedora Linux 36 (Cloud Edition)
• Docker version: docker-ce.x86_64 3:23.0.3-1.fc36
• Docker compose version: docker-compose-plugin.x86_64 2.17.2-1.fc36

Command used to run the container

• docker compose start
• docker compose up

Docker compose file

services:
  kimai:
    container_name: kimai
      image: kimai/kimai2:apache-2.0.10-prod
      volumes:
        - data:/opt/kimai/var
        - /opt/docker/kimai/config/local.yaml:/opt/kimai/config/packages/local.yaml
        - /opt/docker/kimai/config/php-memory-limit.ini:/usr/local/etc/php/conf.d/php-memory-limit.ini
        - /opt/docker/kimai/plugins/:/opt/kimai/var/plugins/
      ports:
        - 8001:8001
      environment:
        - ADMINMAIL=[redacted]
        - ADMINPASS=[redacted]
        - DATABASE_URL=[redacted]
        - TRUSTED_HOSTS=nginx,localhost,127.0.0.1,[redacted domain]
      restart: unless-stopped

volumes:
  data:

[tobybatch]

How are you reloading the caches? Can I see the command please? Or is that as part of the start up script?

BTW - Also the 2.x version is currently unsupported as it's unreleased. It only sneaked out into the wild coz I made a little f**k up.

[TSmigielski]

First, I need to get into the container with docker exec -it kimai /bin/bash, then cd to /opt/kimai, and at last the command that is provided in the documentation: bin/console kimai:reload --env=prod.

Ownership / permissions get reset after using this command, and also on a restart of the container / app. How it's done on startup exactly I have no clue.

As for "this" being a "fk up", I find it pretty funny, since I've been using 2.0.0 since December/January in my** company of 6 people in total. I remember the initial set up was kind of rough, though it was some time ago, so I can't quite remember why exactly. Other than the setup, so far we've encountered a single bug, which was not being able to create a tag from the time entry creation modal, which I just checked, is now fixed in 2.0.10. And other than that the app has been working flawlessly until now.

[tobybatch]

I'm sure Kevin is really happy to see 2.x being used in the wild. I will, of course, migrate to 2.x when it's properly released.

The reason you are getting that permission reset is because you are attaching to the container as root.

tobias@trafalgar:/opt/dockers$ docker exec -ti kimai-mysql-testing bash
bash-4.4# id
uid=0(root) gid=0(root) groups=0(root)
bash-4.4#

The www-data user has a shell of no-login so you can't just su across to them, try this:

docker exec -ti --user www-data kimai bash

or in fact you could even run the whole command from the docker exec command:

docker exec -ti --user www-data kimai /opt/kimai/bin/console kimai:reload --env=prod

[TSmigielski]

Okay, so I have just run some more tests on my side.

After fixing the permissions, reloading the cache as www-data user works as expected.

However, restarting the container, either with docker compose restart, or rebooting the "whole" server, which causes the docker service to stop and start, which in turn restarts all containers effectively; Causes the same issue, of resetting permissions of the cache and ownership.

To test this, I have simply run the docker compose restart command, and as expected, I got the 500 http code when trying to access the site. Then I tried to reload the cache as the www-data user, but got the output down below. Which obviously means the permissions got reset. After that, I have simply "fixed" the permissions/ownership, and reloaded the cache, which fixed the 500 http status code, and I could access the app again.

www-data@210437a8ca5d:/opt/kimai$ bin/console kimai:reload --env=prod

Reloading configurations ...
============================

[OK] All 26 YAML files contain valid syntax.

[OK] All 578 XLIFF files contain valid syntax.

Rebuilding your cache, please be patient ...

[ERROR] Unable to write in the "/opt/kimai/var/cache/prod" directory.

[WARNING] Cache could not be rebuilt.

Please run these commands to rebuild the cache manually:

rm -r var/cache/*
bin/console cache:clear --env=prod
bin/console cache:warmup --env=prod

[tobybatch]

So, I'm not sure when I built this image but there was an old bug that reset those permissions. I have another user that wants the latest 2.x image built. Let me build and push (manually) that and we can see if it fixes that issue.

That will be 2.0.14

[tobybatch]

I've just pushed

kimai/kimai2:apache-2.0.14-prod
kimai/kimai2:apache-2.0.14-dev
kimai/kimai2:fpm-2.0.14-prod
kimai/kimai2:fpm-2.0.14-dev

[TSmigielski]

Alright, I have updated to the new 2.0.14 version, and the bug is gone! Good job

[kevinpapst]

@tobybatch please tell me, that 2.0.14 is not the "latest" now.

[tobybatch]

No, don't panic, just tagged. :)

[kevinpapst]

Phew, good 😄 I am still not ready with the plugins...