我不知道为什么,但是,umount在docker中不起作用。
"umount: loop3/: must be superuser to umount"
让我再分享一件事
它会在真实机器的loop3
下创建/mnt/loop3
。对我来说这是最意想不到的事情,因为承诺纯虚拟环境。
为什么呢?任何解决方案?
Docker Linux机器:(ubuntu)
Linux 626089eadfeb 3.10.45-1-lts #1 SMP Fri Jun 27 06:44:23 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Linux机器:( Arch Linux)
Linux localhost 3.10.45-1-lts #1 SMP Fri Jun 27 06:44:23 UTC 2014 x86_64 GNU/Linux
Docker Info
Client version: 1.0.1
Client API version: 1.12
Go version (client): go1.3
Git commit (client): 990021a
Server version: 1.0.1
Server API version: 1.12
Go version (server): go1.3
Git commit (server): 990021a
答案 0 :(得分:12)
我找到了解决方案:
在默认的docker中,它不像我们期望的那样是真正的操作系统。它没有访问设备的权限。因此,我们必须在运行docker时使用 --privileged
。
默认情况下,Docker容器为"unprivileged"
,但不能在Docker容器中运行Docker守护程序。这是因为默认情况下不允许容器访问任何设备,但"privileged"
容器可以访问所有设备。
当操作员执行 docker run --privileged
时,Docker将允许访问主机上的所有设备,并在AppArmor中设置一些配置,以允许容器几乎所有相同的访问权限托管作为在主机上的容器外运行的进程。
答案 1 :(得分:0)
在我的情况下,它是linux的mount命令,但对unmount
也有效。
先前的解决方案是有效的,但是我的场景无法执行命令'docker run
',因为它是实时使用的。
我想挂载的命令:
mount -o remount,size=5G /dev/shm
泊坞窗中的验证:
[docker]$ df -h
Filesystem Size Used Avail Use% Mounted on
shm 64M 4.0K 64M 1% /dev/shm
[docker]$ exit
我们寻找容器的ID:
$ docker ps
CONTAINER ID IMAGE
<container_id> nameimage
让我们记住ID的开头
以下所有命令必须使用sudo
(在最短的时间内使用)执行:
# sudo -i
我们转到包含docker的文件夹:
# By default
cd /var/lib/docker/containers/
然后我们打开以开头的文件夹。
cd <container_id>
我们使用必要的参数执行命令:
mount -o remount,size=5G shm
(注意:我不记得是否必须执行命令才能显示文件系统)
最后我们进入Docker并验证值是否已正确更新:
[docker]$ df -h
Filesystem Size Used Avail Use% Mounted on
shm 5.0G 0 5.0G 0% /dev/shm