You might also want to consider setting the systemd services to run as the bacula user with the User= directive. While people with tapes drives might not want this for the SD the dir should most likely be run as user bacula.

I also want to point out you may not want to use Restart=always even though I included it in the above services.

This is in rel -2.

I appreciate the quick inclusion of the changes but I do see some things that probably should be changed. I've experienced the director failing if it isn't able to connect to the database. This is a possibility on startup if we don't require the bacula-dir.service to start after postgresql.service and mysql.service. I also propose we change the permissions of the files from 0755 to 0644 like the other services and conf files. I also rashly included the Restart=Always line in the bacula-fd service which can cause a lot of trouble when trying to diagnose fd startup failures. I'm not exactlly sure how the reopen process works but I will be sure to comment with my proposed file changes. Thanks.

This should be worked out with the more recent issue I posted providing a PKGBUILD patch and this should be permanently closed. Did I request this be reopened before coming up with a better fix?

Hello!

I'm using bacula-postgresql from AUR, but completely based on this 'official' build and, after migrating my machine to systemd, I have permission problems...

Is it everything OK?

I wonder because of this line:

d /var/run/bacula/ 2775 bacula bacula -

in bacula.conf, for which I'm not 100% what it does.

First problem is that I get permission problem to access /etc/bacula/conf files, but after chowning them to bacula:bacula, now I get:

Message delivery ERROR: Msg delivery error: fopen /var/cache/bacula... denied

Any hint?

Sorry but what is this bug report about now and what do you want me to do? Bacula works fine here.

I think he is running into permission problems since the dir and sd both run as the bacula user instead of root now. I personally have not run into any issues when using the bacula user, although i have changed all of the configurations and their owners.

@William: Right. I also wonder if Sven is running bacula with HD or tape drive?

I'm the latter user and will try to tweak bacula-postgresql (which was running fine with init scripts) according to Fedora's package).

I'm using a tape auto changer (but currently don't have access to it)

@William: "I personally have not run into any issues when using the bacula user, although i have changed all of the configurations and their owners." What does it mean?

My tape is chowned as root:storage 660 and I've problem accessing it. Any hint?

I get perm. denied for all root owned files despite bacula-fd starting as root:root, but in atop I see that bacula-fd is reported as RUID=bacula, EUID=bacula, so I wonder why bacula-fd drops its privileges to bacula:bacula?

Tried to start bacula-fd by hand and it keeps root:root privileges, while under systemd it drops 'em to bacula:bacula: :-/

I'm reall curious how it works at your side...my change is only that I use postgresql...

We found the problem...somehow there was another set of bacula service files in /etc/systemd where bacula-f had option: User=Group=bacula which is overriding service files in /usr/lib/systemd and therefore all our tweaking did not not have any effect. :-/

Now what do I make of this? I'm using initscripts and can't test systemd stuff. I kind of hoped you guys would provide the right input here.

@Sven: "Now what do I make of this? I'm using initscripts and can't test systemd stuff."

I don't understand why you wrote: "Bacula works fine here." when I also wrote "...after migrating my machine to systemd, I have permission problems..." ?

I hoped it is obvious that the problem is/was systemd-related.

"I kind of hoped you guys would provide the right input here." - I believe that "We found the problem..." shows that bacula is now working with systemd support. :-)

So I can close this bug?