Re: could not open file "global/pg_filenode.map": Operation not permitted

postgres@arcict.com

From: Nick Renders <postgres@arcict.com>
To: pgsql-general@lists.postgresql.org
Date: 2024-03-28T15:47:44Z
Lists: pgsql-general
On 22 Mar 2024, at 17:00, Alban Hertroys wrote:

> On Fri, 22 Mar 2024 at 15:01, Nick Renders <postgres@arcict.com> 
> wrote:
>
>>
>> We now have a second machine with this issue: it is an Intel Mac mini
>> running macOS Sonoma (14.4) and PostgreSQL 16.2.
>> This one only has a single Data directory, so there are no multiple
>> instances running.
>>
>
> I don't think that having a single Data directory prevents multiple
> instances from running. That's more of a matter of how often pg_ctl 
> was
> called with the start command for that particular data directory.
>
>
>> I installed Postgres yesterday and restored a copy from our live 
>> database
>> in the Data directory.
>
>
> How did you restore that copy? Was that a file-based copy perhaps? 
> Your
> files may have incorrect owners or permissions in that case.
>
>
>> The Postgres process started up without problems, but after 40 
>> minutes it
>> started throwing the same errors in the log:
>>
>>         2024-03-21 11:49:27.410 CET [1655] FATAL:  could not open 
>> file
>> "global/pg_filenode.map": Operation not permitted
>>         2024-03-21 11:49:46.955 CET [1760] FATAL:  could not open 
>> file
>> "global/pg_filenode.map": Operation not permitted
>>         2024-03-21 11:50:07.398 CET [965] LOG:  could not open file
>> "postmaster.pid": Operation not permitted; continuing anyway
>>
>
> It's possible that some other process put a lock on these files. 
> Spotlight
> perhaps? Or TimeMachine?
>
>
>> I stopped and started the process, and it continued working again 
>> until
>> around 21:20, when the issue popped up again. I wasn't doing anything 
>> on
>> the machine at that time, so I have no idea what might have triggered 
>> it.
>>
>> Is there perhaps some feature that I can enable that logs which 
>> processes
>> use these 2 files?
>>
>
> IIRC, MacOS comes shipped with the lsof command, which will tell you 
> which
> processes have a given file open. See man lsof.
>
> -- 
> If you can't see the forest for the trees,
> Cut the trees and you'll see there is no forest.


I have tried the lsof command, but it returns no info about the 
postmaster.pid and global/pg_filenode.map files, so I take they are not 
open at that moment.

Spotlight indexing has been disabled, and TimeMachine takes no snapshots 
of the volume where the data resides.

Looking at the 2 machines that are having this issue (and the others 
that don't), I think it is somehow related to the following setup:
- macOS Sonoma (14.4 and 14.4.1)
- data directory on an external drive

That external drive (a Promise RAID system in one case, a simple SSD in 
the other) has the option "ignore ownership" on by default. I have tried 
disabling that, and updating the data directory to have owner + 
read/write access for the postgres user. It seemed to work at first, but 
just now the issue re-appeared again.

Any other suggestions?

Thanks,

Nick Renders

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Remove the restriction that the relmap must be 512 bytes.