Another thought: if it's not a sharing violation, I wonder if we should consider dumping more raw Windows error information in the messages we log, because, if I recall correctly, we're converting many Windows error codes into few Unix-style error numbers and thereby throwing away valuable clues. It makes it a bit more confusing when trying to ask a Windows expert what might be happening.
Knowing process name holding file and other detailed information
would be very useful.
In other Win 2019 server/Postgres 13 excluding Postgres drive from fprot scan seems to decrease those errors.
However they still occur even if no fprot is active.
There are also regular stat errors in windows servers is size
queries like
ERROR: could not stat file "base/45010/172654232": Permission
denied;
in query
SELECT pg_size_pretty(pg_database_size('eeva')::bigint)::char(10) as size
and
ERROR: could not stat file "base/45010/172654232": Permission
denied;
in query
SELECT
pg_catalog.pg_size_pretty(SUM(
CASE WHEN pg_catalog.has_database_privilege(d.datname,
'CONNECT')
THEN pg_catalog.pg_database_size(d.datname)
ELSE 0
END)::bigint) ::char(50) AS SIZE
FROM pg_catalog.pg_database d
and
ERROR: could not stat file "base/45010/172654232": Permission
denied;Error while executing the query
SELECT d.datname::char(15),
pg_catalog.pg_get_userbyid(d.datdba)::char(18) AS Owner,
CASE WHEN pg_catalog.has_database_privilege(d.datname,
'CONNECT')
THEN
pg_catalog.pg_size_pretty(pg_catalog.pg_database_size(d.datname)::bigint)
ELSE 'No Access'
END::char(50) AS SIZE
FROM pg_catalog.pg_database d
ORDER BY
CASE WHEN pg_catalog.has_database_privilege(d.datname,
'CONNECT')
THEN pg_catalog.pg_database_size(d.datname)
ELSE NULL
END DESC -- nulls first
Andrus.