Just to clarify, earlier in this script at line 134:

mkdir -p "/tmp/docker-mailserver/opendkim/keys/${DKIM_DOMAIN}"

We create this parent location if it doesn't exist yet. So the only difference here with chown is that the user has created this location in advance or adjusted the permissions since?

I am curious about the motivation for this as most content in the DMS config volume will be owned by root:root when it's created by DMS?

Docker hasn't landed official convenience options for the linux kernel mounting API feature (idmapped mounts), but you can use it manually AFAIK, while I think podman implemented the feature for rootful volumes.

For Docker I think it'll need to wait for Containerd 2.0 release, and then some release after Docker upgrades to that and implements the feature (been a long wait since Kernel 5.12 introduced the feature in April 2021).

ID mapped mounts will allow mapping root from the container easily to another user on the host with volume mounts, avoiding the need to chown effectively..

in the compose.yaml /tmp/docker-mailserver is mapped as a volume (we have an earlier version of the compose.yaml but it behaves the same) so when a user has a directory containing docker-data that belongs to him it is problematic if there is data created for root:root that the user cannot manage outside of the container (e.g. adding the dkim public keys to DNS).

Yes I understand, but this is admin not related to mail users per se. It can happen with other configs too, not just the DKIM keys generated.

The data should still be readable IIRC, and you rarely need to interact with this kind of data manually on the host for writes? Usually it's annoying if you want to move/rename or delete from the host due to the root ownership.

If you have ID mapped mounts however (once they're in a release that makes it easier to configure), this whole issue disappears.

yes, sorry my "user" is me the mail admin needing to manage the dkim keys ;-)

i wanted to make the smallest fix to fix my/our issue without affecting too much other stuff. ideally i would think DMS should respect the owner of /tmp/docker-mailserver when creating files there but that would be a much bigger change.

And not all data was readable (transfering private keys from the system i'm working on to the real server after testing was not working without using sudo chown locally, cleanup of CI systems failed without sudo chown).

ideally i would think DMS should respect the owner of /tmp/docker-mailserver when creating files there but that would be a much bigger change.

We could probably add ENV similar to the VMAIL_UID + VMAIL_GID actually and chown to that when necessary? Then it could work for all cases when you opt-in, without having to know the folder to create in advance (or manually chown the first time) which this fix relies on?

cleanup of CI systems failed without sudo chown

Our tests have a make clean that is meant to handle that. If it doesn't we can fix that issue.

Our approach is to just run a container as root with the volume mounted and remove as root that way. I definitely remember the annoyance of relying on sudo from the Docker host in the past, while the tests prior did this on the host you'd have to provide your password upfront and I felt uncomfortable about the script removing content on the host system it had full access to vs removing with the restricted volume.

For CI it's less of an issue to just have a sudo step IMO 🤷‍♂️

Anyway this is fine and we can get this into v13.3 :)