Red Hat Bugzilla – Bug 443223
Tablespace creation failure: could not set permissions on directory
Last modified: 2013-07-02 23:17:32 EDT
When an attempt is made to create a tablespace, where the tablespace directory
exists, the ownership is correct, and the permissions have been correctly set to
0700, and SELinux is *disabled*, the following error occurs:
postgres=# CREATE TABLESPACE fma LOCATION '/home/chandler/fma/db/pgsql';
ERROR: could not set permissions on directory "/home/chandler/fma/db/pgsql":
The problem comes down to the following piece of code within postgres, which
incorrectly tries to set the permissions on the tablespace directory to 0700.
What the code is trying to do is to ensure the permissions are set to 0700 by
setting the permissions to 0700. What the code should be doing is testing that
the permissions are 0700, and throwing an error if this is not the case.
This saves the admin going on a wild goose chase trying to work out why the
postgres user cannot chmod a directory owned by the postgres user to 0700, when
the permissions are already correctly set in the first place.
01284 * Attempt to coerce target directory to safe permissions. If this
01285 * fails, it doesn't exist or has the wrong owner.
01287 if (chmod(location, 0700) != 0)
01290 errmsg("could not set permissions on directory \"%s\": %m",
As the comment says, the chmod should succeed if the directory is both accessible to and owned by the
postgres user; and if either of those conditions doesn't hold, we can't use the directory anyway. (I suspect
the failure in this case was because some upper-level directory in the path had the wrong permissions.)
So I see no bug here. If you can point out a real-world case where the chmod wouldn't work and yet it'd
be all right to use the directory, I might reconsider.
As it turned out, the postgresql server had cached permission credentials, so
while the postgres user could see the directory without a problem, this was not
possible by postgresql until the server could be restarted from scratch.
Going off to Google found a number of hits about it not being possible to chmod
a directory if you are not the superuser under certain, and with the addition of
SELinux the wild goose chase was assured.
Ideally the error message should suggest that the server might need to be
restarted before the permissions take effect.
Per the concurrent discussion in pgsql-admin, there is no obvious reason why a restart would help. I
think you might possibly have a reason to file a kernel bug here, but it's not a postgres bug.