Cronjob doesn't run? Also, how to run `restic` process as root?

[alichaudry]

Question 1
I've had a discussion here about this as well as some related issues, but I've noticed that my container exits after the initial backup job. This is certainly non-ideal as one would be expecting their data to be regularly backed up, only to find their resticker container exited months prior and they've lost all their data.

My hypothesis is that the container exits if restic returns a non-zero outcome. I assume this is the case because my initial (i.e., startup backup job) ends with:

processed 6131477 files, 12.343 TiB in 3:19
snapshot a5a4f8d saved
Warning: at least one source file could not be read
Backup incomplete
Finished backup at 2025-04-02 15:34:44 after 205 seconds

and the container seems to be down. My expectation is that the backup job would continue despite errors in the backup job. Or at least continue for non-fatal errors (like the one above, where a few files in the source had permissions that were not owned by my user).

Question 2
A related question is, how do I run the container or the restic process as root? I want to ensure the source files are copied properly and with the correct owners/permissions, which only the root user would be able to do. I see some of my other docker containers/services running as the non-1000 user (and even as root), so I'm guessing there should be a way to start this container as root so it can access/backup all files it encounters (and without having to run all my docker containers as sudo a la sudo docker compose up -d).

[smainz]

Question 1:

I have not observed this, but why don't you just use a restart policy in your docker command?
docker run --restart=unless-stopped See: https://docs.docker.com/engine/containers/start-containers-automatically/

Question 2:

You can set any user / group you like in the container using docker run --user 0:0
See: https://docs.docker.com/reference/cli/docker/container/run/#options

Same works for docker compose, just a slightly different syntax https://docs.docker.com/reference/compose-file/services/

[alichaudry]

@smainz thank you for your response:

• I prefer not to keep restarting the container as it does a pretty large backup (on the order of hours), so any restarts would trigger this all over again. My hope is to have the service/container start up, run the backup (RUN_ON_STARTUP: "true"), and then only run as per the cron scheduler defined by me. Perhaps I'm misunderstanding it, but is this not how this is supposed to function?
  • The large backup is from an unrelated problem that's causing it to not find the parent snapshot.
• Thank you for the insight on running as root. I'll give that a shot.

[alichaudry]

Specifically on running as root, I tried that w/ user: root in my docker-compose file, and I continued to observe the same permission errors as before:

error: open /mnt/to_backup/machine/var/mail/root: permission denied
error: openfile for readdirnames failed: open /mnt/to_backup/machine/var/spool/cron/crontabs: permission denied
...

[djmaze]

Specifically on running as root, I tried that w/ user: root in my docker-compose file, and I continued to observe the same permission errors as before:

@alichaudry Everything in the container runs as root by default. If you have permissions problems, it must be something different (maybe these are network mounts)?

To see what actually is the case could exec into the running container and look at the permissions, i.e. docker exec <container name> stat /mnt/to_backup/machine/var/mail/root.

[djmaze]

I prefer not to keep restarting the container as it does a pretty large backup (on the order of hours), so any restarts would trigger this all over again. My hope is to have the service/container start up, run the backup (RUN_ON_STARTUP: "true"), and then only run as per the cron scheduler defined by me. Perhaps I'm misunderstanding it, but is this not how this is supposed to function?

The container should not exit when there are backup errors. I don't yet understand why this happens to some people.

As a workaround, you could set restart: always on the container and set RUN_ON_STARTUP: "false". In this way the container will be restarted after an attempt with an error, and backup again on the regular schedule.

[djmaze]

@alichaudry Everything in the container runs as root by default. If you have permissions problems, it must be something different (maybe these are network mounts)?

Maybe you run on a rootless docker instance or on one with user namespace mappings?