6/10: clash tun带来的问题，就是有比较小的概率会无法连上一个网站，但是如果重试又正常了。但是测试下来如果直接用http proxy就比较正常，如果不想要重建容器，那么就把
http_proxy="<http://clash:[email protected]:7890>"
https_proxy="<http://clash:[email protected]:7890>"
no_proxy="localhost,127.0.0.1,.local,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"
这几行塞到/etc/environment里面去，可以直接用http proxy，来绕过上面的问题，但是对于git push、pull之类的东西，因为是走ssh协议，就管不到这个，还是会正常地被tun接管
6/8: 如果拉不下来模型，感觉是因为被开了hf_xet，不会吃 HF_ENDPOINT，导致只能走代理，但是组里的代理看起来对这个支持不好。 huggingface-cli download 的时候加上 HF_HUB_DISABLE_XET=False 来避免用xet
在特定容器内与NFS挂载目录交互时，可能会遇到文件权限问题
- 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
- fish：
- 这个可能会影响整个系统在解压tar包的时候的行为，包括可能apt会tar解压的时候如果有其他权限的文件，也会被一并被影响到，因此没有默认应用到所有的镜像中
- 将
- workaround
- Podman in Podman启动psql、mysql、apache、httpd这些会主动修改自己的文件数据的软件
- 如果将NFS的路径挂载到了这一些容器里面，会导致程序chown失败，还不清楚是否会影响程序的正常启动
- workaround
- 将本地的文件系统挂载到容器中作为持久化的
- 如果
/root和/mnt/data都是NFS挂载过来的，找管理员开一个本地文件系统的，或者开一台新的机器
- Cursor Server的安装，cursor会尝试解包一个包含了
- 这个会影响的程序包括
conda create失败
- 如果比较长的时间还是这样，可能是conda的锁没有被释放，那直接用下面的命令直接清理掉锁
conda clean --locks