Bug 1376453
Summary: | bacula-sd reports "Permission denied" on device though running as root | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | André Schramm <andre.schramm> |
Component: | bacula | Assignee: | Josef Ridky <jridky> |
Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.8 | CC: | andre.schramm, yves.mulleneers |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2016-09-20 11:45:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
André Schramm
2016-09-15 13:08:34 UTC
Thank you for this report. This issue has been discussed with upstream authors with following results: 1) The main problem is in different versions of the Director and the SD. Bacula does not support running with different versions of the Director and SD. Versions supported DIR == SD (only) FD <= DIR/FD So different DIR and SD is not supported and in general will not work. And the FD must be the same version as the DIR/SD or older, but not newer. 2) When is first point resolved and if the permission problem still persist on the SD which is running with root, it is probably because the SELINUX is enabled and the rules have not been appropriately adapted. The Bacula project does not use or support SELINUX. While Red Hat welcomes bug reports on Red Hat products here in our public bugzilla database, please keep in mind that bugzilla is not a support tool or means of accessing support. If you would like technical support please visit our support portal at access.redhat.com or call us for information on subscription offerings to suit your needs. I have got one more highlight to this topic from upstream. I have put the message from upstream below. ---- UPSTREAM MESSAGE ---- I think that this behavior is caused by wrong Bacula usage by the user. Please look at following steps that user did (with my comments): 1) [root@bacula-sd ~]# /usr/libexec/bacula/mtx-changer /dev/sg5 load 1 /dev/nst0 0 To load/unload volume in storage managed by Bacula, the user has to umount the storage first. Otherwise Bacula SD will have wrong tape drive state remembered and from this reason Bacula can try load volume already loaded or can try unload volume not loaded. 2) [root@bacula-dir ~]# bconsole *status storage=Quantum-Changer ... Device status: Autochanger "Quantum-Changer" with devices: "LTO5" (/dev/nst0) Device "LTO5" (/dev/nst0) open but no Bacula volume is currently mounted. Drive 0 status unknown. Total Bytes Read=0 Blocks Read=0 Bytes/block=0 Positioned at File=0 Block=0 ==== ... In this output the "no Bacula volume is currently mounted" state means that Bacula SD doesn't know about loaded tape from slot 1 to tape drive /dev/nst0. So, before loading volume by mtx-changer the storage wasn't unmounted (it was mounted). 3) *label storage=Quantum-Changer pool=LTO5-Pool slots=1-3 barcodes It can fail because of above problem. 4) *unmount storage=Quantum-Changer It can fail because of above problem. 5) [root@bacula-sd ~]# /etc/init.d/bacula-sd stop All Bacula SD devices are freed. 6) [root@bacula-sd ~]# cp /etc/init.d/bacula-sd /etc/init.d/bacula-sdd I am not sure if it is required. 7) [root@bacula-sd init.d]# /etc/init.d/bacula-sdd start After starting Bacula SD, all devices are mounted again and tape drives (with volumes or without) are initialized in Bacula SD. *label storage=Quantum-Changer pool=LTO5-Pool slots=1-3 barcodes Devices were mounted and initliazed correctly, so no error. *unmount storage=Quantum-Changer Devices were mounted and initliazed correctly, so no error. ---- END OF MESSAGE ---- Please let us know if the message was helpful for you. Thanks for your reply. To put it short: We don't think this is a bug in Bacula, but rather in the CentOS init script or sth. related. Otherwise we would have directly reported it to the Bacula team. And we did not use the CentOS bug tracker as it would have ended up here anyway. A short summary would be: the error "Permission denied" goes away if one simply renames /etc/init.d/bacula-sd to /etc/init.d/bacula-sdd and starts the latter. Nothing else is changed in any of the configuration files, only the name of the init script. Basically, we were trying to set up a new/second tape lib in an existing scenario. The snippets from bconsole do not show everything we did, but should only show the difference between the actual and expected command outputs. Let aside the tape loading behind Bacula's back (which would have confused it) and the unmount on a not mounted tape (which nevertheless flawlessly worked in the second example). The label scenario was Bacula with the new tape lib and all tapes unlabeled. Running the label command after starting /etc/init.d/bacula-sd gives "Permission denied" and detects no slots in the changer. Simply running /etc/init.d/bacula-sdd works as expected: 40 slots are detected and the tapes are labeled correctly. So it looks like the name of the init script somehow interferes with something else and/or causes "Permission denied". But what was important was the "DIR == SD" constraint. Though I checked up the versions compatibility list [1] beforehand, I only focused on the FD. So our current setup with different versions of DIR and SD might be working (as it does with /etc/init.d/bacula-sdd), but is not officially supported and we'll have to change it anyway. It thus is unclear whether it is worth debugging this bug within the current setup. [1] http://wiki.bacula.org/doku.php?id=versions_compatibility Bacula Storage Deamon is executed as user bacula. On my system this user must be added to group tape. This command solved the 'permission denied' problem. # usermod -a -G tape bacula Obviously, tape devices are owned by group tape. Thanks for your reply. As the topic states, the SD was running as root when the error occurred. I came across "Bug #905530 - bacula-director runs as root not bacula user" and it was the same for the SD at that time. I tried the solution from #905530 to run SD as user bacula, which was added to the tape group before. As this did not work, I changed SD_USER and SD_GROUP back to root. This was done on a customer system I no longer have access to, so I cannot provide any further information. Thanks for your help and this Bugzilla account is hereby closed. |