It took me a while to realize that backups were running as a user account instead of as root - I didn’t even think to check that since other backup apps I used had their worker process running as root by default.
I found the comment saying the file owner of the backup plan is what it is run under, so it is possible to set ownership to root. But that’s something that has to be remembered every time a plan is made.
Either having the backup worker run as root in the first place (safest) or at least having an option in the backup plan creation wizard (functional but possibly confusing to people) would be better.
Actually setting the owner of the plan file doesn’t seem to be impacting anything.
In this screenshot you’ll see that I am running 3 plans right now and they are all running as my user account. (which is an admin, but still seems to be having permissions issues)
However, in the other screenshot you’ll see that I have set all but one test plan to be owned by root & wheel.
[reply=“Don P;3910”] The plans are running under the account that was used to create them. You can call that a security measure. You can always change plan owner to root via this command:
If that doesn’t help check what the actual permissions on the files:
ls -la $target_folder_with_permission_denied_files
Pay attention to the user-group-other and owner settings.
It might be that the files were denied to access by our Backup user and you may need to allow our Backup to read those files.
To do so, run chmod +r $target_folder_with_permission_denied_files/*
I get that you can change the ownership via the command line, my point is this should be a GUI option. Require admin password to be entered at the time of changing it, that’s how most apps deal with this kind of thing. But as long as this ‘hidden’ from the user, people are going to have files missed in their backups.