should not touch populated volume by default

[fallenguru]

I gave a copy of my existing /opt/fhem directory to the docker image as a volume, expecting it to more or less run as-is. To my surprise, running the image changed the ownership and permissions of all files & directories, ruining my setup. It's setup just so, with a couple of files, notably fhem.cfg, read-only to the fhem user by default, for a reason!

Easily restored of course, but I don't think the container setup should meddle around in the external volume at all, that sort of defeats the point of keeping code and data/configuration separate.

[jpawlowski]

This change is on particular purpose and won't be changed. Proper permissions are essential for FHEM to operate and this is what the image ensures.

You might want to pay attention to the configuration options mentioned in the README.md file, in particular the UID/GID customizations.

[fallenguru]

It's your project of course, but

• IMHO docker containers should not under any circumstances modify data in volumes, or the configuration of the host system. This isolation is the whole point of using docker.
• If the container requires a certain environment, document it, by all means check for it in a script and throw a warning, or fail with an error, but do not just go ahead and silently modify the system.
• I've been running fhem for years, the ownership & permissions are set properly, and in a fine-grained manner. How is carpet-chown-ing and -chmod-ing everything to be the same good practise?

[jpawlowski]

FHEM has special requirements that this images helps you with. It is not and it can not be a typical Docker image whatsoever. Due to its speciality, no container best practices apply.

This image is build for easiness, user friendliness and peace of mind. It is not for hardcore users who want to be in control of every bit. The latter requires extensive knowledge and if you have that knowledge, you can surely build your own environment and do not need to use this image.