PostgreSQL COPY 导入 CSV 报 Permission denied，文件却能在终端读取
CSV 在终端可读，SQL COPY 仍可能因数据库服务用户无法访问父目录而失败。区分服务端与 psql 客户端读取位置，用客户端导入并在提交前核对数据。
在终端能打开 CSV，文件权限也是 0644，放进下面的 SQL 后却报错：
COPY public.import_items (item_id, item_name)
FROM '/home/operator/import/items.csv'
WITH (FORMAT csv, HEADER true);
ERROR: could not open file "/home/operator/import/items.csv" for reading: Permission denied
这里的文件由 PostgreSQL 服务进程读取。登录终端的用户能读，不代表数据库服务的操作系统用户也能读；数据库账号拥有超级用户权限，也不能替服务进程绕过操作系统的文件权限。
如果 CSV 本来就在运行 psql 的电脑上，通常可以改用 psql 的 \copy，让客户端读文件，再把数据传给数据库。下文说明如何判断读取位置并完成导入。Linux 目录权限的说明适用于服务端读取失败；命令示例采用 psql，不能直接粘贴到只接受 SQL 的网页查询编辑器中。
先确定文件到底由谁打开
SQL COPY ... FROM '/path/file.csv' 中的路径属于数据库服务器。连接远程数据库时，它不会自动上传本机文件。数据库运行在容器内时，路径还必须在数据库进程所见的文件系统中存在。
psql 的 \copy ... FROM '/path/file.csv' 则由运行 psql 的进程打开文件。你在笔记本上运行 psql，文件就应在笔记本上；SSH 登录另一台机器后运行 psql，文件就应在那台机器上；在容器里运行 psql，则应从那个容器的视角检查文件。
可在当前 psql 会话中查看连接信息，确认导入目标：
\conninfo
同时确认启动这个 psql 的操作系统用户能读取目标 CSV。不要仅凭连接信息里的数据库用户名判断文件权限，它和操作系统用户是两套身份。
如果实际错误是 must be superuser or have privileges of the pg_read_server_files role，那是服务端文件访问的数据库权限门槛，与这里的文件打开失败不同。当前 PostgreSQL 支持通过相应预定义角色授权服务端文件读取，但这类授权范围较大。只为导入客户端文件，无需先给业务账号授予该角色或超级用户权限。
文件可读，父目录仍可能挡住数据库
在 Linux 上，打开一个文件需要能够逐级搜索它的父目录。目录的 x 位表示搜索权限；仅有目录读取权限并不足够。
例如 CSV 为 0644，但某层父目录为 0744，数据库服务用户又不属于目录所有者，那么传统权限位就没有给它目录搜索权限。即使文件对所有用户可读，服务进程也可能在到达文件之前就收到拒绝访问。
判断时要同时核对文件、每层父目录和数据库进程的实际运行用户。若路径包含符号链接，还要看链接目标经过的目录。传统权限位看起来正确时，也不能据此排除其他访问控制或挂载环境的限制。
不要反复扩大 CSV 的权限，也不要为导入一份文件递归修改整个家目录。把数据移动到公共临时目录同样可能扩大暴露范围。文件本来就由当前客户端持有时，改用客户端读取，往往能避免调整服务端目录权限。
用 psql 的 \copy 读取客户端文件
以下是完整语法示例。public.import_items 必须是已经存在、允许你写入的目标表，item_id、item_name 按 CSV 中的列顺序列出；路径换成运行 psql 的环境中实际存在的文件。示例假设第一行为表头，内容以逗号分隔。
\copy public.import_items (item_id, item_name) FROM '/home/operator/import/items.csv' WITH (FORMAT csv, HEADER true)
请把整条 \copy 写在同一物理行。它有自己的参数解析方式，不能照搬多行 SQL 的排版，也不会在参数中执行普通 psql 变量替换。路径有空格时保留单引号，并填写实际路径。
HEADER true 会跳过输入文件的第一行；没有表头的文件要去掉这个选项或设为 HEADER false。它不按表头名称自动重排列，列清单仍须与数据顺序对应。分隔符、编码、空值表示和数据类型也必须符合文件实际格式。
这一步改变的是文件读取位置。数据库仍会检查目标表的写入权限、约束和触发器，不能借此绕过表权限。开启行级安全的表还有额外边界：当前 PostgreSQL 不支持对这种表使用 COPY FROM，改成 \copy 也不会解除这一限制。
在提交前确认导入了什么
COPY FROM 会向表追加数据。看到权限报错消失后，不要连续重试直到“看起来正常”，否则前一次已经提交的导入可能被重复追加。
先确认目标库、表结构、备份和去重规则；生产数据应按既定导入流程先进入测试库或专用暂存表。对于已经评估过约束和触发器影响的目标表，可以在同一个交互式 psql 会话中显式开启事务，完成一次导入后再决定提交：
BEGIN;
\copy public.import_items (item_id, item_name) FROM '/home/operator/import/items.csv' WITH (FORMAT csv, HEADER true)
成功时 psql 会显示 COPY n，其中 n 是此次复制的行数。将它与本批数据的预期记录数比较，并按业务主键核对样例字段、空值及重复情况。CSV 字段可以包含换行，文件的文本行数未必等于记录数。
确认无误后单独执行：
COMMIT;
发现目标错误、行数异常，或导入在该事务中失败，则执行：
ROLLBACK;
回滚用于撤销这个尚未提交事务里的数据库更改。不要将它当成触发器外部副作用的通用恢复手段，也不能用它撤销此前已经提交的导入。已提交的数据需要按批次标识、业务主键及备份制定恢复方案，不能直接清空原表。
如果改用 \copy 后变成客户端文件的 Permission denied，说明当前 psql 进程仍不能读取文件，应检查客户端这侧的路径和权限。如果出现类型转换、列数不符或唯一约束错误，则已经进入另一个检查阶段，应针对具体错误调整数据或导入映射，继续扩大文件权限不会解决它。
必须保留服务端 COPY 的批处理任务，应为数据库进程安排受控的导入目录，只授予所需的目录搜索和文件读取权限，并记录原权限便于恢复。仅凭这条报错没有依据关闭安全模块、重启数据库或给文件开放所有人的写权限。