Permissions being reset

i have - PUID=1000 - PGID=1000 for emby/embyserver and I always chown -R 1000:1000 /data/emby and recreate the container but for some reason this thing always resets everything to being owned by bin:bin

Did you check the dockerhub description if PUID and PGID are supported and used by a container (based on the image) to actualy do what you expect?

it is yes

docker run -d \
    --volume /path/to/programdata:/config \ # This is mandatory
    --volume /path/to/share1:/mnt/share1 \ # To mount a first share
    --volume /path/to/share2:/mnt/share2 \ # To mount a second share
    --device /dev/dri:/dev/dri \ # To mount all render nodes for VAAPI/NVDEC/NVENC
    --runtime=nvidia \ # To expose your NVIDIA GPU
    --publish 8096:8096 \ # To expose the HTTP port
    --publish 8920:8920 \ # To expose the HTTPS port
    --env UID=1000 \ # The UID to run emby as (default: 2)
    --env GID=100 \ # The GID to run emby as (default 2)
    --env GIDLIST=100 \ # A comma-separated list of additional GIDs to run emby as (default: 2)

Can you spot the difference between what you posted in your initial post and what you pasted from the dockerhub description?

Also, on Linux you can use the command stat /data/emby on the host, to see the exact UID and GID of the (changed?) owner.

➜  ~ stat /data/emby
  File: /data/emby
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 810h/2064d	Inode: 42205185    Links: 11
Access: (0775/drwxrwxr-x)  Uid: (    2/     bin)   Gid: (    2/     bin)
Access: 2020-03-11 01:13:17.352510423 +0000
Modify: 2020-03-01 01:18:02.477439896 +0000
Change: 2020-03-11 01:09:02.360176509 +0000
 Birth: -

oh wow i have a P in there
i thought the P was just docker-compose’s way of saying uid?

You did spot it now :slight_smile:

Environment variables have to be used exactly(!) as documented in the description.

Some images run a system daemon as root and execute the main application using a restricted user. The parameter UID:GID on this particular image are used for that matter. Some images provide this sort of behavior. This is NOT a docker feature - it is introduced entrypoint behavior by the image maintainer. This is the beginner friendly approach :wink:

Docker itself uses -u to set the UID and if you want the GID) for the first declared USER in the Dockerfile. Those type of images usualy run with a restricted user and are not able to fix ownership for you. This approach is less beginner friendly, but the favored one, as it does not mess with your permissions and the container is already started as a restricted user.