Docker Compose integration permissions issue on macOS

[pjv]

Which version of Mutagen are you using (mutagen version)?

0.12.0-beta2

Which operating system (platform/version/architecture) are you using?

macOS 10.15.6
docker desktop v. 2.3.0.4 (46911) [stable channel]

What is the issue that you're experiencing?

I’m having some trouble with permissions in my container mounting a couple of mutagen-synced volumes. Below is an excerpt of my docker-compose.yml:

volumes:
  wordpress:
    external: true
  wp-content:

x-mutagen:
  sync:
    defaults:
      permissions:
        defaultOwner: "id:1000"
        defaultGroup: "id:1000"
        defaultFileMode: 644
        defaultDirectoryMode: 755
      ignore:
        vcs: true
    wordpress:
      alpha: "../wordpress"
      beta: "volume://wordpress"
    wp-content:
      alpha: "./wp-content"
      beta: "volume://wp-content"

I’m mounting both those named volumes in a linux-derived php container like so:

    volumes:
      - wordpress:/var/www/html
      - wp-content:/var/www/html/wp-content

The issue is that the wordpress volume is (to me, correctly) being mounted in the container with uid:gid 1000:1000, but the wp-content volume is mounting with uid:gid root:root.

I’ve seen mention of the fact that the mutagen sidecar service / container runs as root and that there are workarounds by targeting a subdirectory of the named volume somehow. Indeed, everything inside the wp-content mount in the php container is 1000:1000, but I need wp-content itself to also be 1000:1000. I tried mangling the alpha and beta urls many different ways, but I can’t figure out how to get the wp-content mountpoint where I need it in the container with the permissions I need it to have. Doubly confounding that the wordpress volume mounts as 1000:1000 which I assume is somehow due to it being an external volume.

[pjv]

May be the same issue as #224 (?)

[xenoscopic]

I think this is indeed the same issue as #224, and I think the suggestion there of having the sidecar container act as the entity for changing permissions is probably the only answer since it doesn't seem like Docker is going to add a mechanism to configuring this anytime soon (though, of course, that would be hugely preferable).

I'll have to do some experimentation though to understand how this behaves, because the volumes are really just directories on the Docker host filesystem and I'm not sure if permissions set on the mountpoint in the container filesystem namespace will propagate to the directories on the host (or even other containers with separate filesystem namespaces). As long as they "stick" from the perspective of the container(s), I think it should be okay either way, I'm just uncertain about the longevity of such settings for external volumes and the visibility from other containers. I do know that if UID/GID ownership is set on the Docker host, then those permissions will be visible at the mountpoint, but Linux namespace behavior can be fickle, so testing will be the only way to know.

[xenoscopic]

i'm going to close in favor of #224 for now and continue the discussion there.