Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjHni-00CLZe-1p for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Jan 2026 14:06:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjHng-0004hB-1G for pgsql-bugs@arkaria.postgresql.org; Fri, 23 Jan 2026 14:06:12 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjHMV-00028r-2R for pgsql-bugs@lists.postgresql.org; Fri, 23 Jan 2026 13:38:08 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjHMT-001v8F-0G for pgsql-bugs@lists.postgresql.org; Fri, 23 Jan 2026 13:38:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=0NCQPlbaIGuG4SdXf5vB2B9CQYJU+pH+6HWcKhjb8ck=; b=YR6Kk/+kQEBv7LSFyud7oeKv5g 2ufvNYSGp5tY2wjKxpwAjG1R53kEjUGCnGBne1rQ2/+4VeO96eFIfTTD+QrCkzFV9s52qMxnmhmgy G67GEkXcYeRrm+VeysJYoaWfnV6ugqoZYToTmgmM+l+i3l0BiHgrJFKw02C3M3qIIWSUksW0hjcRl rP3hNxMhadbgiayTJ2nWLaC3sfxIXOkOoFIpDffu6rHwNaeWGgjU1OmQsd1YW7wT7Y433y8GYr0Tn 2av+QTgmVAPwAbr7NSN0THtEJAaPRV1nT4r/o2OB8QXM1Vlvh4UfFcPKpvdI8oQFgd72DZVApv2IK 0qOjOIkg==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vjHMS-005aGH-1d for pgsql-bugs@lists.postgresql.org; Fri, 23 Jan 2026 13:38:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vjHMQ-009q8r-0a for pgsql-bugs@lists.postgresql.org; Fri, 23 Jan 2026 13:38:02 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19388: Failing to connect to postgres with EACCES error To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: gc.nugent66@gmail.com Reply-To: gc.nugent66@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 23 Jan 2026 13:37:08 +0000 Message-ID: <19388-c49c361739e2eb3c@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19388 Logged by: George Nugent Email address: gc.nugent66@gmail.com PostgreSQL version: 17.7 Operating system: Linux Description: =20 Running on k8s pods, I have an issue where a process cannot connect to an Azure Postgres server due to a permission error. 1782279 1769097264.122469 openat(AT_FDCWD, "/home/xxxxx/.postgresql/root.crl", O_RDONLY) =3D -1 EACCES (Permission denied) 1782279 1769097264.122535 stat("/home/xxxxx/.postgresql/postgresql.crt", 0x7fcdd85a2de0) =3D -1 EACCES (Permission denied) We use standard SSL without client certificates and the running process is setup without a homedir for security reasons. I noticed from the postgres source code that only ENOENT & ENOTDIR are allowable errors but EACCES is a fail condition. I understand the reasoning for checking for existence of certificates, but can the Permission Denied error also be treated as "Can't get client certs, continue to try to connect without"?