Databricks中Notebook间本地文件写入权限问题排查

以下是针对该权限问题的具体排查方向：

1. 验证进程的有效组身份 #

用户所属的附属组（spark-users）不一定会被进程默认使用。在第二个Notebook中执行以下命令，确认进程实际的有效组和可用组列表：

import os
print("有效GID:", os.getegid())
print("进程可用组:", os.getgroups())

如果os.getegid()返回的是用户自身的spark-xxx组ID，而非spark-users的GID，说明进程默认以主组身份运行，无法利用附属组的写入权限。这种情况下，需要确保进程运行时切换到spark-users组（例如通过os.setegid(gid)临时切换，或调整Notebook的启动配置）。

2. 检查文件的ACL权限 #

Linux ACL可能存在超出基础权限位的限制，执行以下命令查看文件的详细ACL设置：

getfacl /tmp/test123_1

如果输出中包含deny规则或针对特定用户的限制，会覆盖基础的组权限设置。

3. 确认文件是否被锁定 #

如果第一个Notebook未正确关闭文件句柄，或其他进程持有文件锁，会导致写入失败。执行以下命令检查文件的占用情况：

lsof /tmp/test123_1

若有进程占用文件，需终止相关进程或确保文件句柄被正确关闭。

4. 检查系统安全模块限制 #

部分集群会启用SELinux或AppArmor等安全模块，即使权限配置正确也会拦截跨用户写入操作：

• 查看SELinux状态：getenforce，若显示Enforcing，可临时关闭测试：setenforce 0，再次尝试写入。
• 查看系统日志（/var/log/audit/audit.log或/var/log/syslog），查找与/tmp/test123_1相关的权限拒绝记录。

5. 验证权限是否被后续操作篡改 #

某些Spark集群的自动清理机制或Notebook会话的后置脚本，可能会自动重置文件权限。在权限修改后立即重新查看权限，然后间隔一段时间再次检查，确认权限是否保持稳定：

ls -l /tmp/test123_1

补充测试建议 #

在第二个Notebook中尝试追加写入而非覆盖写入，验证是否是写入模式的问题：

f = open("/tmp/test123_1","a")
f.write("append test")
f.close()

如果追加成功但覆盖失败，需排查是否集群对文件截断操作有额外限制。

内容的提问来源于stack exchange，提问作者404