Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm migrating a CentOS 5.3 system from MySQL to PostgreSQL. The way our machine is set up is that the biggest disk partition is mounted to /home. This is out of my control and is managed by the hosting provider. Anyway, we obviously want the database files to be on /home for this reason.

With MySQL, we did the following:

  • Edited my.cnf and changed the datadir setting to /home/mysql
  • Added a new "File type" policy record (I hope I'm using the right terminology) to set /home/mysql(/.*)? to mysqld_db_t
  • Ran restorecon -R /home/mysql to assign the labels

and everything was good.

With PostgreSQL, however, I did the following:

  • Edited /etc/init.d/postgresql and changed the PGDATA and PGLOG variables to /home/pgsql/data and /home/pgsql/pgstartup.log, respectively
  • Added a new policy record to set /home/pgsql/pgstartup.log to postgresql_log_t
  • Added a new policy record to set /home/pgsql/data(/.*)? to postgresql_db_t
  • Ran restorecon -R /home/pgsql to assign the labels

At this point, I still cannot start PostgreSQL. pgstartup.log says:

# cat pgstartup.log
postmaster cannot access the server configuration file "/home/pgsql/data/postgresql.conf": Permission denied

The weird thing is that I don't see any messages related to this in /var/log/messages or /var/log/secure, but if I turn off SElinux, then everything works.

I made sure all the permissions are correct (600 for files and 700 for directories), as well as the ownership (postgres:postgres).

Can anyone tell me what I am doing wrong?

I'm using the Yum repository from, version 8.3.7.

EDIT: The reason my question specifically mentions the /home directory is that if I go through all these steps for any other directory, e.g. /var/lib/pgsql2 or /usr/local/pgsql, then it works as expected.

share|improve this question

This thread looks relevant -

share|improve this answer
Thanks very much for the link. Unfortunately, it looks like I am already doing exactly what I am supposed to -- namely, changing the SELinux policy to allow PostgreSQL to access the specific directories I need. Furthermore, the steps I took do work, for any place other than a directory in /home. – Matt Solnit Jul 1 '09 at 20:34

First check the label on the conf file. Poking around on a Centos5.3 system I see

semanage fcontext -l | grep "postgresql_etc_t"
/etc/postgresql(/.*)?                              all files          system_u:object_r:postgresql_etc_t:s0

and policy says

sesearch -A -s postgresql_t -t postgresql_etc_t
Found 3 av rules:
allow postgresql_t postgresql_etc_t : file { ioctl read getattr lock }; 
allow postgresql_t postgresql_etc_t : dir { ioctl read getattr lock search }; 
allow postgresql_t postgresql_etc_t : lnk_file { read getattr };

try to do an

ls -Z /home/pgsql/data/postgresql.conf

If the label isn't right there are various ways to change it. A quick google gave me

semanage is one way. If you want to try to do a quick test try

chcon -t postgresql_etc_t /home/pgsql/data/postgresql.conf

Also make sure that the postgresql daemon is running in the right domain (ie SELinux context). You might quickly find that it is not by tailing the logs, see below. see run_init for details on kicking off an init script so that it is in the right domain. posgresql might be running as unconfined_t (in which case there shouldn't be a problem, unconfined gets to do a lot).

There may be other issues with SELinux for further analysis try tailing the audit log. (note that the audit log isn't written to until auditd is up, I've been bitten by that before. In that case check /var/log/messages for pre auditd log messages)

Try and see what SELinux might be complaining about

tail -f /var/log/audit/audit.log

or to look just for denials

tail -f /var/log/audit/audit.log | grep denied

Then try the same access ie start the deamon.

share|improve this answer

did u check out u r #SESTATUS

[root@yeswedeal ~]# sestatus SELinux status: disabled

share|improve this answer
Hi Rajat. SELinux is enabled. – Matt Solnit Jun 28 '09 at 21:55
Hi Matt Solnit Production server normally [root@yeswedeal ~]# sestatus SELinux status: disabled it should be disabled – Rajat Jun 29 '09 at 5:36
No, running without SELinux enabled on a production server is a BAD idea. – Ophidian Jul 29 '09 at 23:24

Even if you have labeled the directories correctly, it is quite possible that the selinux policy forbids postgresql from acessing /home itself (the link mentioned in @Milen's answer, in fact, seems to imply that).

share|improve this answer
Hi CesarB. I'm not sure I understand. Are you saying that SELinux treats /home as a special case, even if I label it correctly? That certainly sounds like what I'm seeing, but I didn't see anything in Milen's link that refers to /home. – Matt Solnit Jul 1 '09 at 20:37

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.