这很奇怪，虽然我有一个解决方法，但我更喜欢永久的解决方案。
我有一小部分运行 Ubuntu 14.04 的 GPU 机器，我将其用作受 Docker 镜像影响的云服务的工作器。我有nvidia-docker安装在所有工作机器上，以便 docker 可以访问 GPU。工作机器还可以作为单独的服务器，实验室成员可以直接在上面进行实验（学术环境、云服务是实验性的，等等）。对于后一个目的，所有机器都通过 NFS 自动挂载单个用户共享。我们最近从静态 fstab 配置切换到自动挂载，我仍然在习惯它——这里很可能存在一些明显的问题，我没有看到，因为我是一个自动挂载新手。最后，我还没有为 docker 镜像设置任何东西来访问 NFS 共享，所以理论上应该没有连接……理论上。
本周，我们实验室的一名成员Too many levels of symbolic links在尝试从其中一台 GPU 机器访问其共享驱动器时报告了错误。据他们所知，他们根本没有使用 docker。他们的树中没有可疑的符号链接（通过find -type l），因此一定是其他东西进入了奇怪的状态。挂载点ls -l在父目录中如下所示：
dr-xr-xr-x 2 root root 0 Dec 5 18:38 labmember1
这似乎……糟糕？root:root 555，真的吗？当你尝试浏览它时，你得到的确实是：
$ cd /path/to/labmember1/
-bash: cd: /path/to/labmember1/: Too many levels of symbolic links
该共享似乎实际上并未被挂载 —— 它没有出现在 /etc/mtab 中，并且（可以预见地）尝试手动卸载它并报告：
$ sudo umount /path/to/labmember1/
umount: /path/to/labmember1/: not mounted
重新启动 autofs ( service autofs restart) 没有任何反应。
我当时认为这无关紧要：docker 一直在到处散布 veth 接口。这是一台被积极用作云工作者的机器，所以我认为这是我们的云软件。现在我不太确定了。
今天，Too many levels of symbolic links另一台 GPU 机器也出现了故障，该机器安装了 docker/nvidia-docker，但没有运行云工作者软件。瞧，到处都是 veth 接口，尽管数量比云工作者机器少得多。
一时兴起，我停止了 docker 服务 ( service docker stop)。太神奇了！共享正常挂载，我们实验室成员可以再次使用他们的东西。重新启动 docker 后，共享仍处于工作状态。
因此，如果再次发生此问题，我可以通过重新启动docker来解决这个问题，但我想知道
- 这到底是什么原因造成的？或者，我怎样才能找出答案？
- 有什么办法可以防止这种情况再次发生，还是每次发生故障时我都只能修理它？
答案1
您是如何定义挂载选项的autofs， /etc/auto.master您是进行直接还是间接自动挂载？
另外，您是否autofs完全在 Docker 容器内，并--privileged在 docker run 命令中添加了选项？使用此方法，您应该能够毫无问题地执行 NFS 挂载。
autofs请注意，无法将挂载绑定到正在运行独立 autofs 守护程序的容器中，因为它可能与原始命名空间中运行的 autofs 守护程序冲突。
对于间接挂载，autofs在根命名空间中运行可通过将 autofs 顶级挂载绑定到具有 Docker 卷选项的容器中来为 Docker 容器提供自动挂载，其功能基本可以按预期运行。
答案2
root@slave2:~# cd /home/client/
-bash: cd: /home/client/: Too many levels of symbolic links
解决方案：
root@slave2:~# cd /home/
root@slave2:/home# umount client
然后重新挂载文件路径。