From: Josh F. <jf...@pv...> - 2011-06-30 18:11:23
|
On 6/30/2011 1:28 PM, Victor Hugo dos Santos wrote: > On Tue, May 3, 2011 at 11:05 AM, Josh Fisher<jf...@pv...> wrote: >> So, bacula:bacula cannot write, but bacula:disk can, yet all accessed >> directories appear to be owned by bacula:bacula? What group does the >> bacula-sd daemon run as? On Fedora, it is typical for bacula-dir to run >> as bacula:bacula, while bacula-sd runs as bacula:disk. Perhaps this is >> an selinux thing? Maybe the simple solution is to change everything to >> be owned by bacula:disk and run bacula-sd as bacula:disk. > Hi... > > I had the same error today in ubuntu server: > > ================ > $ sudo vchanger -u bacula -g bacula /etc/bacula/disco_usb.conf initmag 1 > magazine bay 1 has no magazine mounted > > $ sudo vchanger -u bacula -g tape /etc/bacula/disco_usb.conf initmag 1 > magazine bay 1 has no magazine mounted > > $ sudo vchanger -u bacula -g disk /etc/bacula/disco_usb.conf initmag 1 > magazine in bay 1 (/mnt/vchanger/29d9d497-62dd-4903-9054-a3fb9777b79d) > already initialized as magazine 1 > ================ > > bacula-dir and bacula-sd are working in "bacula" and "tape" groups > respectively and all folders and files have this groups. > > ================= > $ find /var/lib/bacula/ /var/log/bacula/ /var/bacula -not -group > bacula -and -not -group tape > /var/log/bacula/ > ================= > > and after check the output of strace > > ================= > $ sudo strace -s 100 vchanger -u bacula -g bacula > /etc/bacula/disco_usb.conf initmag 1 > > stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 > time(NULL) = 1309454624 > stat64("/dev/sdc1", {st_mode=S_IFBLK|0660, st_rdev=makedev(8, 33), ...}) = 0 > open("/dev/sdc1", O_RDONLY|O_LARGEFILE) = -1 EACCES (Permission denied) > read(4, "", 1024) = 0 > close(4) > ================= > > I found that the problem is that vchanger try to access the device > (/dev/sd*) directly and not the directory/mountpoint configured.. Could be. If magazines are specified by UUID, then libblkid functions are used to discover the device node with that UUID, followed by a getmntent() call to query the mountpoint path. Either libblkid or getmntent() is very likely making the stat64() call on the device node. > and how the script are running with a group (bacula/tape) that don't > have access do /dev/sd*, the script don't work... > > =========== > $ ls -ltr /dev/sd* > brw-rw---- 1 root disk 8, 16 2011-06-28 11:16 /dev/sdb > brw-rw---- 1 root disk 8, 0 2011-06-28 11:16 /dev/sda > brw-rw---- 1 root disk 8, 1 2011-06-28 11:16 /dev/sda1 > brw-rw---- 1 root disk 8, 17 2011-06-28 11:16 /dev/sdb1 > brw-rw---- 1 root disk 8, 21 2011-06-28 11:16 /dev/sdb5 > brw-rw---- 1 root disk 8, 18 2011-06-28 11:16 /dev/sdb2 > brw-rw---- 1 root disk 8, 32 2011-06-30 12:10 /dev/sdc > brw-rw---- 1 root disk 8, 33 2011-06-30 12:10 /dev/sdc1 > =========== > > solution... mmm .. include bacula in disk group ?? That, or run bacula-sd as bacula:disk, rather than bacula:tape, if that is possible. The user bacula-sd runs as needs read-only access in order to look up the mountpoint using a getmntent() call. |