• Rootless Podman与User Namespace：Rootless Podman依赖Linux的user namespace功能，将容器内的用户ID（例如容器内的root用户UID 0）映射到宿主机上一个非特权的用户ID范围。详见https://www.redhat.com/en/blog/rootless-podman-user-namespace-modes
• NFS与User Namespace的不兼容：NFS协议本身设计上不支持user namespace。它依赖于服务器和客户端之间对UID和GID的一致性理解。
• 导致的问题：当容器尝试在NFS挂载的目录中执行需要改变文件所有权的操作（例如 chown），并试图将文件所有者设置为仅在容器的user namespace中有效的UID时，NFS服务器无法识别或处理这个来自特定namespace的UID，从而导致操作失败。
• 这个问题只存在于操作的目录是一个NFS挂载过来的目录，可以通过 df -T $path 来检查，查看里面的 Type 是 nfs4 还是 zfs
  • 这个会影响的程序包括
    • Cursor Server的安装，cursor会尝试解包一个包含了 1000:127 权限的文件，而当前在容器中的用户是root，会尝试将这个权限应用到这个文件上。由于上面所说的问题，使得chown失败，进而影响cursor的server启动失败
      • workaround
        • 将 export TAR_OPTIONS="--no-same-owner --no-same-permissions" 添加到rc文件中
        • rc文件指
          • fish： ~/.config/fish/config.fish
          • bash： ~/.bashrc
          • zsh： ~/.zshrc
        • 这个可能会影响整个系统在解压tar包的时候的行为，包括可能apt会tar解压的时候如果有其他权限的文件，也会被一并被影响到，因此没有默认应用到所有的镜像中
    • Podman in Podman启动psql、mysql、apache、httpd这些会主动修改自己的文件数据的软件
      • 如果将NFS的路径挂载到了这一些容器里面，会导致程序chown失败，还不清楚是否会影响程序的正常启动
      • workaround
        • 将本地的文件系统挂载到容器中作为持久化的
        • 如果 /root 和 /mnt/data 都是NFS挂载过来的，找管理员开一个本地文件系统的，或者开一台新的机器