Postgres Pro
Downloads
Home   >   mailing lists

Thread: pg_basebackup fails with Could not stat file or directory "./.pg_hba.conf.un~"

pg_basebackup fails with Could not stat file or directory "./.pg_hba.conf.un~"

From
"Stephens, Gary"
Date:

Hi,

 

I’m writing to report a bug with pg_basebackup. It fails with this error:

 

pg_basebackup: error: could not initiate base backup: ERROR:  could not stat file or directory "./.pg_hba.conf.un~": Permission denied

 

The file in question is a temporary file created by vim, and has the same permissions and security context as the file that it was editing (pg_hba.conf).

 

It's unclear to me why pg_basebackup is trying to read this file. It's also unclear why it's failing when it does try to read it, since the file has the same permissions and security context that should allow the instance to read it (even though the backup really shouldn’t need to read it).

 

The directory where it resides is /var/lib/pgsql/data (this is where pg_hba.conf resides as well).

 

Please note: After I removed the file, the backup ran normally. I have not tested to see whether other temp files in the same directory would cause a similar failure.

 

Database version:

postgres=# select version();

                                                   version

-------------------------------------------------------------------------------------------------------------

PostgreSQL 13.7 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 8.5.0 20210514 (Red Hat 8.5.0-10), 64-bit

 

Thanks,

 

Gary Stephens

Enterprise Holdings, Incorporated



CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and may contain confidential and privileged information protected by law. If you received this e-mail in error, any review, use, dissemination, distribution, or copying of the e-mail is strictly prohibited. Please notify the sender immediately by return e-mail and delete all copies from your system.

Re: pg_basebackup fails with Could not stat file or directory "./.pg_hba.conf.un~"

From
"David G. Johnston"
Date:
On Tue, Mar 7, 2023 at 1:37 PM Stephens, Gary <Gary.Stephens@ehi.com> wrote:


It's unclear to me why pg_basebackup is trying to read this file.


Because that is what it is documented to do:

https://www.postgresql.org/docs/current/app-pgbasebackup.html

> The backup will include all files in the data directory and tablespaces, including the configuration files and any additional files placed in the directory by third parties, except certain temporary files managed by PostgreSQL.
 

It's also unclear why it's failing when it does try to read it, since the file has the same permissions and security context that should allow the instance to read it (even though the backup really shouldn’t need to read it).


Understandable, but not a pg_basebackup bug that it is being told it lacks permission.  But I suspect there is file locking involved and it isn't a file permission problem.

David J.

Re: pg_basebackup fails with Could not stat file or directory "./.pg_hba.conf.un~"

From
Francisco Olarte
Date:
Hi David:

On Tue, 7 Mar 2023 at 22:32, David G. Johnston
<david.g.johnston@gmail.com> wrote:
> Understandable, but not a pg_basebackup bug that it is being told it lacks permission.  But I suspect there is file
lockinginvolved and it isn't a file permission problem.
 

Besides locking I've encountered this kind of problems with people
having a habit of editing non-root-owned config files as root with
editors which do not take care of setting permissions. An ls -l of the
offending file is normally useful, or the version with all extended
acl/attrs which I'm unable to recall now.

Francisco Olarte.

Re: pg_basebackup fails with Could not stat file or directory "./.pg_hba.conf.un~"

From
Tom Lane
Date:
Francisco Olarte <folarte@peoplecall.com> writes:
> Besides locking I've encountered this kind of problems with people
> having a habit of editing non-root-owned config files as root with
> editors which do not take care of setting permissions. An ls -l of the
> offending file is normally useful, or the version with all extended
> acl/attrs which I'm unable to recall now.

Yeah, "ls -lZ" to see SELinux labels.  It's easy to forget about those
if you're not pretty used to them.

            regards, tom lane