Error access denied when using persistant volumes in docker

[paschki0n]

Hi,
I'd like to run semaphoreui in docker with persistant volumes for config and tmp.

I would normally specify in compose.yml the user/group id under which the container should run and the path.

... user: "${UID}:${GID}" volumes: - /path_to_folder/config/:/etc/semaphore:rw - /path_to_folder/tmp/:/tmp/semaphore:rw ...
I've not been able to use persistance volumes as the user semaphore does not exist on the host running docker and therefor has no access to the folder. Using UID/GID causes problems with the container setup as the user ID is 1001, not knowing the UID/GID I pass to the container.
Any advise who to fix this would be welcome ?
Thanks

[fiftin]

@tboerger can you help?

[tboerger]

Currently there is no fix for customizing the uid/gid, it is hardcoded. If you are not able to give the host folder to uid 1001 you could at least try some docker plugin like https://github.com/clecherbauer/docker-volume-bindfs where you can use bindfs to map from host uids to container uids.

[pixeldoc2000]

@tboerger
Is support for UID/GID on the roadmap?

IMHO fixed UID in container is kind of PITA.

[bverkron]

Agree, this is fairly problematic for running automations against the host filesystem and requires doing a clunky "loopback" approach where you SSH into the host or similar. That's not too terrible in principle but not always practicle or even necessarily possible.

For example Unraid only allows the root user to use SSH and I'm not going to setup root SSH for this as it's a big security no-no. Arguments can be made for setting up 3rd party SSH servers via another container, etc but all of this just because Semaphore doesn't support running as a different user is a real hassle.

[pixeldoc2000]

@tboerger

docker plugin like https://github.com/clecherbauer/docker-volume-bindfs where you can use bindfs to map from host uids to container uids.

https://github.com/clecherbauer/docker-volume-bindfs has been archived by the owner on May 8, 2024. It is now read-only and there is no active fork.

Maybe it is time to reevaluate UID/GID support?