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": Permission denied 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. 01283 /* 01284 * Attempt to coerce target directory to safe permissions. If this 01285 * fails, it doesn't exist or has the wrong owner. 01286 */ 01287 if (chmod(location, 0700) != 0) 01288 ereport(ERROR, 01289 (errcode_for_file_access(), 01290 errmsg("could not set permissions on directory \"%s\": %m", 01291 location)));
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.