Hi Rich,
Thank you for the quick reply.
Great tip, selinux is indeed enabled.
We currently run Red Hat Directory Server 9.0 on Red Hat Enterprise
Linux 6 64 bit.
This is what selinux suggests (/var/log/messages):
Do
# semanage fcontext -a -t FILE_TYPE '/backup_cds'
where FILE_TYPE is one of the following: var_lock_t, tmp_t, tmpfs_t,
dirsrv_config_t, dirsrv_tmp_t, dirsrv_tmpfs_t, dirsrv_var_lock_t,
var_lib_t, var_run_t, var_log_t, dirsrv_var_log_t, dirsrv_var_lib_t,
dirsrv_var_run_t, pcscd_var_run_t, tmp_t, root_t, krb5_host_rcache_t.
Then execute:
restorecon -v '/backup_cds'
To fix it I used:
ls -l -Z /var/lib/dirsrv/slapd-examplesrv/bak
-rw-------. root root unconfined_u:object_r:dirsrv_var_lib_t:s0 dsbck1.tgz
So then :
chcon --reference /var/lib/dirsrv/slapd-examplesrv/bak /backup_cds/
and
restorecon -v '/backup_cds'
Then it worked!
Thank a lot!
Sorry for missing this, I hope it helps others too :).
Greetings Vincent
On Mon, May 13, 2013 at 5:48 PM, Rich Megginson <rmeggins(a)redhat.com> wrote:
On 05/13/2013 09:09 AM, Vincent Gerris wrote:
>
> hi,
>
> I noticed this entry when trying to use the db2bak.pl script.
> I found out that the -a option only works when for example
> the /var/lib/dirsrv/slapd-server/bak or a subdir is used (effectively)
> the same dir as without the -a option.
> I was using a root dir, which I also modded with nobody:nobody as
> owner en chmod 777, but still no result.
> Is this a bug, or does the server somehow checks the dir?
By default we protect certain directories with SELinux. What platform?
What version of 389-ds-base?
> The backup script for an old iPlanet server does it too and is able to
> use /local/bla without a problem.
> Seems like a bug to me?
>
> Greatings
> Vincent
> --
> 389 users mailing list
> 389-users(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/389-users