rootless volume (ownership/permissions of local volume)

[Kamtsa]

Unsure if this is the best place to ask, since this is not specific to this seafile image, but a general docker or seafile-image question. Maybe someone here has encountered and solved the same problem, given the emphasis on a clean image and service design!

TL;DR : docker-compose option like user: "1000:1000" for user permissions on local folder/volume seafile-data?

I am running a variety of different docker services on arm and x86-64, besides seafile-clients and seafile-server via docker-compose, as non-root user. I back these up via daily cronjob scripts that essentially take the container down, archive the entire docker folder via borg, and then bring container back up. For that to work I've made all config folders local volumes, and all external folders mapped in docker-compose.yml . Seafile-server is my last service still needing/having folders with non-user permissions, for which as a clutch I use some root owned cronjob to first rsync the entire docker-seafile-server folder and later on backup this mirror as user. For all other services I've found some kind of 'rootless' option, most of the time as well placed version of option user under some service in docker-compose.yml. I don't really know what I'm doing when it come to building images, and much prefer to use a simple option intended for this purpose. Or maybe I'm approaching this all wrong and the permission issue is just a red herring?

I have been running the stock (haiwen) image via their docker-compose.yml for a few years now, and other users reported similar ideas but no solution. This only affects seafile-server, the docker-compose.yml for seafile-client has user permissions out of the box. I've been playing around with this image for a couple of days, running it in parallel on about ~700GB of mixed data. The main feature of seafile I'm using in practice is the file version control, data is rarely accessed via web GUI, and distribution is done via resilio-sync or syncthing.

Grateful for any pointers or ideas! (The work-around with root rsync mirror copy works reliably, apart from taking up double the disk space I just don't like it)

[ggogel]

Several ideas and questions came to my mind.

1. Why all the hassle with "rootless" backup?

From a security perspective you make it even worse. By default /var/lib/docker/volumes is only accessible for root users. In your system, the volumes are accessible on user-level. Making it even more vulnerable. What you're doing is essentially copying files on user-level, which should be protected by root-level, just to execute the backup as non-root user. It doesn't make sense. I don't understand why you specifically want to execute the backup as non-root user.

The permission system inside a container is entirely independent from the host system. So for instance if you configure a container to start its app as user with UID X, this UID likely has root access within the domain of the container, while the UID X on your host could be just any user-level user. So additionally, you're trying to bridge permissions from two different domains.

2. Why do you backup the whole docker folder?

It's simply enough to backup the volumes. Since containers are - or at least should be - stateless, there is no need to back them up. The rest of your docker infrastructure, like networks and so on, should be defined by compose files. So when you want to recover from a backup, you just copy in all volumes, apply all compose files and the system should have the same state as before.

3. Why do you stop containers for the backup?

I don't know borg but usually backup software allows you to create snapshots from active databases.

[Kamtsa]

Thanks for your detailed reply! Your points do highlight 'best practices', below I explain why some of your users insist to do weird things, despite the better approach you've explained. (TL;DR: best practices require time now, keeping dumb scripts running can postpone this time investment).

For anyone coming across this post in future with the same question: there is no existing docker-compose.yml option like "user: '1000:1000'" or some once-off chmod/chown command, if case someone really would insist to get "seafile-data" folder to have user permissions, e.g. john:john instead of some random UID mapping root:root or root:systemd-coredump (999 on many systems)?

--
Below is my motivation for wanting to do this - it ended up long and detailed. I'm not expecting any help etc., maybe some developer gets a glimpse how their - great - software is used/abused:

Docker is amongst a handful of tools making quasi-enterprise service available to random private people. E.g. I currently run half a dozen phsyical machines and remote/cloud VM providing things my family is increasingly relying on. I.e. not entertainment things like media streaming but archiving, distributing and organising ten-thousands of documents for admin support, provide remote IT support and communication channels for elderly parents etc. This incurs hardly any financial costs, but maintenance time is the bottleneck: everything is best set up once and then runs fully automatic until it (years later!) breaks, 99.999% reliability is not needed. Security is not the main concern it maybe should be: all machines are locked down and patched up to date, services incl. dockers are not reachable from the outside, and there is no really valuable/private data involved - this is intentionally kept separately. Any hour I spend on tinkering with the tools I need to effectively assist someone, I don't actually assist them - the usual rabbit hole.

I understand and appreciate the points you're making: backing up all 'volumes' in itself is not sufficient, because I don't back up the container image (the correct version might not be :latest when restoring an old snapshot). Each individual dockerised services has likely some better backup solutions than taking down the entire container and snapshotting its volumes. Security should be upheld.

My focus is on streamlining, at times cutting corners with one-size-fits all. My dumb approach is robust and simple, and does not require individual treatment. Maybe my use case has outgrown the scale where dumb is still the best compromise, and I should eventually consider bringing evberything up to better standards :/

Everything user owned/run because it simplifies operations. Borg - an amazing tool in itself - looks from the outside the same as regular ssh/rsync/scp command line, it simply copies a file system to take a snapshot, it needs data to _remain static while backing up. Once some jobs run as root, or some data can only be backed up by root, this gets a lot more complicated. E.g. right now I can remotely control everything, e.g. contrived example:

user@machine1:$ ssh machine2 borg create ...
user@machine1:$ ssh machine2 docker ps ...

There should be no volumes left outside the docker-service's own folder, e.g. nothing in /var/lib/docker/volumes. This is not great, reliable or scales well, but it is simple to set-up, maintain and understand. If seafile-data is owned by root:root as a file system on host either I need pub-keys for root@machine2 for ssh, or remove password request for sudo. Both are bad, I don't want to give up root permissions for the entire system, just for the small part of seafile. My current, dodgy work around is a two punch bandage: cronjob run by host daily brings down container, makes a local file system copy of everything but the container image itself. Separately, relying on separation in time, the regular user does the borg backup on the mirror copy, which now has user permissions. For (rare) restoration permissions need to be reset manually.