On 10/20/22 16:15, Chris Wilkinson wrote:
Thanks for digging this out of the sources, I don't know Bacula well enough to have done that. It seems a wierd choice to hardcode that. I compiled from source as it's on Raspian64 so I could patch and rebuild as you suggest. There may be more to it than the files you found. Not sure about the cron trick as it would be asynchronous to backups possibly creating races.Do you think this qualifies as a bug or just an annoyance? Probably the latter as it doesn't affect as designed functionality.
It was a design choice for sure. No one besides the bacula-sd daemon, running as bacula should really have access to your backup volumes. Another work around for your issue could be to add the user(s) who need to read these volumes to the 'tape' group. This is the more *nix way I would say, and it avoids any possible race conditions you described. Finally, if chmod'ing is an OK option but only if no backup jobs are running, y ou can create a Bacula Admin job that runs a script that does this. Just set the Admin job's priority to a lower priority (higher number) than your backup jobs and it will run when all backup jobs have finished. Hope this helps! Bill -- Bill Arlofski w...@protonmail.com
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
