Standard Docker Image booting but database not writeable

[Haidy777]

Describe the bug
As described in #376 I tried to run the docker image. Sadly without luck. Today I tried again and used the test.sqlite file from the data directory. The DockerImage booted and it seems like it would be working, but the problem is that it seems that the database isn't writeable.

@tobybatch Thanks for the idea with the file.

As before I'm trying to run the whole thing through Plesk, with the Docker Extension.

As you can see there are several Port-Mappings, the working one is 8080 to 32772 which is then proxied through Plesk to a TLD.
Also you can see the Volume-Mapping at the bottom, which links the sqlite-File.

The Error:

I think it has to be something with the file permissions. chmoding it to 777 works, but I don't think that should be the solution.

[tobybatch]

@Haidy777 I've not used plesk myself. The process in the container runs as www-data so the sqlite DB needs to be writable by that user. I think that's it.

chmod 33:33 /root/kimaidata/kimai.sqlite

[tobybatch]

@Haidy777 You may want to use the container that attaches to a SQL DB. https://github.com/tobybatch/kimai2/tree/master/prod

[kevinpapst]

Can you show us an shell output from the kimai directory: ls -la var/data/

[Haidy777]

@tobybatch Thanks for your response. As it's only a testing setup I thought I'll give sqlite only a try.
It works when you chown the file to www-data. Not sure why I didn't test that :)

@kevinpapst I made two screenshots for you, the first one shows the host system, the second one the docker image.

Maybe this step should be added to the docs.

[kevinpapst]

@Haidy777 It was added today: https://github.com/kevinpapst/kimai2/blob/master/var/docs/docker.md#developing-against-the-docker

@tobybatch I tested the ID 33 (as per new docu) on three systems.

Mac OS:
uid=33(_appstore) gid=33(_appstore) groups=33(_appstore),12(everyone),61(localaccounts),701(com.apple.sharepoint.group.1),100(_lpoperator)

Linux version 3.10.0-714.10.2.lve1.4.79.el7.x86_64 (xxx) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP Thu Jan 4 13:30:50 EST 2018
id: 33: User does not exist

Linux version 4.4.0-112-generic (xxx) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5) ) #135-Ubuntu SMP Fri Jan 19 11:48:36 UTC 2018
uid=33(www-data) gid=33(www-data) groups=33(www-data)

Is 33:33 the best command for cross-platform support?

[tobybatch]

It will always be 33:33 because that's the www-data user inside the container and it's that user that needs write permissions.

[kevinpapst]

Aha, okay. So I was wrong because you have to execute the command on the host. I still have a long way to go before I feel confident handling docker ...

Is ist possible to find a permission setting that works inside and outside the box and still is secure?
For example only chgrp 33 kimai.sqlite && chmod g+w kimai.sqlite to prevent permission problems between host and docker.

[kevinpapst]

And btw @Haidy777 SQLite is really only meant for development - I can't safely recommend it for production, as it still has some flaws compared to MySQL.

[tobybatch]

@kevinpapst Yes. As long as the file is writable by both the www-data (33) user and the host user it should work. We can't use ACLs as I don't think they'll bridge over the mount.

The 3.3 symf docs https://symfony.com/doc/3.3/setup/file_permissions.html) include more info than the synf 4 (https://symfony.com/doc/current/setup/file_permissions.html) docs.

[kevinpapst]

Interesting! Maybe I should add these links somewhere in the FAQ, as permission problems come up regularly.

[kevinpapst]

@Haidy777 if the problem is solved, please close the issue

[Haidy777]

Sure, thanks again for the help!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. If you use Kimai on a daily basis, please consider donating to support further development of Kimai.