Setting PUID/PGID?

[sfkpmr]

Would it be possible to add the ability to change PUID and PGID?

I'd like to put my local archive on a NAS, but my file permissions doesn't allow root to put the files there.

[m90]

Running cron as a non-root user is a bit tricky in Alpine which is why I never went down that route (yet). However it would definitely make sense to add this feature.

I think we'd have three options:

• the proper one: run the script as a non-root user in the container, allowing users to map uids and gids from the outside using Docker (this might be a breaking change and require bumping the version to v3)
• the hacky one: when an option like BACKUP_UID is set, create the archive in a temporary location, chown it to the correct owner and then move it over to the location proper with the corre
• the weird one: in https://github.com/m90/targz/blob/master/targz.go see if we can add an option that allows for setting the owner on an archive

The first option would probably be the best, but then I am not sure about the breaking change.

[sfkpmr]

I guess it'd be a bad idea to run a script with cron and change user?

sudo -u anotherUser touch /my/nas/storage/archive.tar.gz

Otherwise maybe Linuxserver can be helpful, they use Alpine and PUID/PGID.

https://docs.linuxserver.io/images/docker-thelounge

[m90]

I guess it'd be a bad idea to run a script with cron and change user?

This is basically what approach 1 is. It's not super pretty, but maybe it's the tool for the job here. This method would need to be taught how to copy to a src with a different user:

docker-volume-backup/cmd/backup/main.go

Lines 682 to 701 in 5a6ce81

	// copy creates a copy of the file located at `dst` at `src`.
	func copyFile(src, dst string) error {
	in, err := os.Open(src)
	if err != nil {
	return err
	}
	defer in.Close()
	out, err := os.Create(dst)
	if err != nil {
	return err
	}
	_, err = io.Copy(out, in)
	if err != nil {
	out.Close()
	return err
	}
	return out.Close()
	}

What's interesting is that jareware/docker-volume-backup (which is an ancestor of this image) does know about setting UID and GID on a backup, but it would also fail in your case (if I understand it correctly) as it's being chowned after it's been copied to the mounted FS: https://github.com/jareware/docker-volume-backup/blob/c3c0d4f4dcd0f9db37bdd9f36bf5f83861a7dec5/src/backup.sh#L117-L123

Otherwise maybe Linuxserver can be helpful, they use Alpine and PUID/PGID.

The Linuxserver docs state: "We are aware that recent versions of the Docker engine have introduced the --user flag. Our images are not yet compatible with this, so we recommend continuing usage of PUID and PGID." so maybe this Docker native behavior should be the way to implement this correctly if you have never supported it until now. That being said, it would definitely be a breaking change as consumer would either have to adjust things after updating or get files owned by a different user.

Also, I'm not entirely sure if this even works as expected as I get files owned by root even when passing PUID and GUID to the image you mentioned:

➜  ~ docker run --rm -it -e PUID=$(id -u) -e GUID=$(id -g) -v $(pwd)/linuxserver-test:/linuxserver-test --entrypoint=ash lscr.io/linuxserver/thelounge
root@672f8f293719:/# whoami
root
root@672f8f293719:/# touch /linuxserver-test/foo.txt
root@672f8f293719:/# 
➜  ~ cd linuxserver-test 
➜  linuxserver-test ls -l
total 0
-rw-r--r-- 1 root root 0 Dez 10 08:36 foo.txt

[sfkpmr]

I spoke to LinuxServer, and it seems you need to run the commands as abc to access the PUID/PGIDs.

I don't know if this complicates things.

$ sudo docker exec -it theloungetest touch /testpath/test/test.txt
touch: cannot touch '/testpath/test/test.txt': Permission denied
$ sudo docker exec -it -u abc theloungetest touch /testpath/test/test.txt
$ sudo docker exec -it -u abc theloungetest ls /testpath/test
test.txt

[m90]

and it seems you need to run the commands as abc to access the PUID/PGIDs.

Thanks for finding this out. This creates the same "problems" as in option 1 as we'd have to make crond play nicely with it. It's possible, but tricky.

By now I think using Docker's user feature would be the best option, I'll try to get that working and in case I succeed, I will need to think about how to handle the versioning (an option would be publishing dedicated tags for this version, e.g. v2.6.0-nonroot)

[sfkpmr]

As you said, using a native --user flag might be the best solution.

[m90]

This turns out to be highly complicated. The user inside of the container will possibly interact with the host's Docker daemon, so it will require root privileges for doing so. Getting all of this mapped correctly will be very hard so I might need to start thinking about the chown on copy solution again.

[m90]

This is turning into a serious rabbit hole and by now I'm not even sure if it's possible to cover your requirements considering the user inside the container will need to interact with the Docker daemon.

In any case I hacked together a test version that uses cp -p for copying files here https://github.com/offen/docker-volume-backup/tree/backup-uid

Would it be possible for you @sfkpmr to build an image off that branch and try using it in your setup (setting BACKUP_UID and BACKUP_GID)? I'm not entirely sure if this works as I surmise cp could also start by creating a root owned file which then changes owner. In case it does not work, we're out of luck here, but in case it does work it might be possible to reimplement the behavior in Go or just keep calling through.

[m90]

Closing this as inactive. Feel free to reopen in case you want to look into this further.