来自守护进程的错误响应:无法杀死容器:权限被拒绝,如何在 Ubuntu 20.04 上杀死 docker 容器?

发布于 2025-01-14 04:23:00 字数 797 浏览 0 评论 0 原文

我试图杀死一个 docker 容器,但我的许可被拒绝。我使用Ubuntu 20.04,客户端的docker版本是20.10.7,服务器的docker版本是20.10.11。

这是我得到的日志:

Error response from daemon: Cannot kill container: fastapi_server: permission denied

我读到我应该使用这个命令来重新启动 docker。

sudo systemctl restart docker.socket docker.service

但问题是,当我执行此命令时,我的所有容器和图像都会消失,但如果我尝试在 localhost:8000 上,我的端口被我想要删除的容器占用。如果我运行 sudo netstat -anp | grep 8000,我得到:

tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN    2493/docker-proxy   
tcp6       0      0 :::8000                 :::*                    LISTEN    2500/docker-proxy 

所以这证实了我的端口已经被 docker 容器占用,但是当我运行 docker ps -a 时,我没有得到任何容器。我也尝试过 docker Kill ,但没有成功。

我应该如何杀死这个容器&释放我的 8000 端口吗?

I'm trying to kill a docker container, but I got permission denied. I use Ubuntu 20.04, my docker version for client is 20.10.7 and the one for the server is 20.10.11.

This is the log I got:

Error response from daemon: Cannot kill container: fastapi_server: permission denied

I read that I should use this comand for restarting docker.

sudo systemctl restart docker.socket docker.service

But the thing is that when I execute this command, all my containers and images dissapear, but If I try on localhost:8000 my port is occupied by the container that I wanted to delete. And if I run sudo netstat -anp | grep 8000, I get:

tcp        0      0 0.0.0.0:8000            0.0.0.0:*               LISTEN    2493/docker-proxy   
tcp6       0      0 :::8000                 :::*                    LISTEN    2500/docker-proxy 

So this confirms that my port is already taken by a docker container, but when I run docker ps -a, I get no container. I also tried docker kill, but it did not work.

How should I kill this container & get my 8000 port free?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(9

愿得七秒忆 2025-01-21 04:23:00

在这些情况下什么对我有用:

sudo systemctl restart docker.socket docker.service
sudo docker image rm -f $(sudo docker image ls -q)

what works for me in these cases:

sudo systemctl restart docker.socket docker.service
sudo docker image rm -f $(sudo docker image ls -q)
谜兔 2025-01-21 04:23:00

看来我已经使用 snap 安装了 docker 并使用了 docker 存储库:

sudo snap list

所以:

sudo snap remove docker --purge
sudo aa-remove-unknown

同时使用描述的方法重新安装 Docker 这里解决了我的问题!无需禁用或删除 apparmor。

It appeared that I had installed docker with snap as well as using the docker repository:

sudo snap list

So:

sudo snap remove docker --purge
sudo aa-remove-unknown

Along with re-installing Docker using the method described here solved my issues! No need to disable or remove apparmor.

蒲公英的约定 2025-01-21 04:23:00

删除 AppArmor 之前请三思。据我了解,这是应用程序安全的核心,例如最近的主要 Ubuntu 版本。

看来权限问题是特定于 Docker 版本的。假设您的 Docker 版本也是通过 snap 安装的,请尝试将您的 Docker 版本至少升级到当前测试版,例如使用

snap refresh docker --beta

20.10.12 似乎工作正常。

(事实上​​,我接受了这个建议,并删除了我的 AppArmor - 快照消失了。然后尽快重新安装,相关快照的设置仍然在我身边 - 后来安装了 docker,遇到问题,升级了它:似乎很有魅力.)

Please think twice before removing AppArmor. To my understanding this is central to application security for instance on recent major Ubuntu versions.

It seems the rights problem is specific to a Docker version. Assuming yours is also installed via snap, please attempt upgrading your Docker version to at least the current beta, e.g. with

snap refresh docker --beta

20.10.12 seems to work fine.

(In fact I fell for the suggestion and did remove my AppArmor - snaps went away. Then reinstalled ASAP, the settings of relevant snaps are still with me - afterwards installed docker back, had the problem, upgraded it: seems to work like a charm.)

空心空情空意 2025-01-21 04:23:00

停止使用以下命令

sudo aa-remove-unknown

Stop using following command

sudo aa-remove-unknown
[浮城] 2025-01-21 04:23:00

尝试以下步骤:

docker inspect

找到 PID 并终止该进程。

如果这不起作用,请检查与

dmesg

Docker 相关的所有内容。您可以将输出放在这里,我们可以帮助您。

好吧,从你的角度看来,你的 AppArmor 有问题。试试这个:

sudo apt purge --auto-remove apparmor
sudo service docker restart
docker system prune --all --volumes

Try these steps:

docker inspect

Find the PID AND kill that process.

If that does not work check with

dmesg

everything related to Docker. You can put output here that we can help you.

Ok,from you png ist seems that you have problem with AppArmor. Try this:

sudo apt purge --auto-remove apparmor
sudo service docker restart
docker system prune --all --volumes
蓬勃野心 2025-01-21 04:23:00

我从 snap 安装了 Docker,并遇到了权限被拒绝的错误响应。在阅读了许多用户在 apparmor 建议中遇到更多问题后,我从 snap 中卸载了 Docker,然后使用 digitalocean 的 Docker 安装教程

它对我有用,在这里发布作为遇到同样问题的其他人的参考。

I installed Docker from snap and experienced the permission denied error response. After reading many users experiencing more problems with the apparmor suggestion, I uninstalled Docker from snap, then used digitalocean's Docker installation tutorial.

It worked for me, posting here as reference for others experiencing the same problem.

千年*琉璃梦 2025-01-21 04:23:00

就我而言,从 Bionic 升级后,它在 Ubuntu 20.04 上也是 apparmor。通过运行 dmesg 我收到错误消息:

[1113458.482007] audit: type=1400 audit(1672134271.112:1718): apparmor="DENIED" operation="signal" profile="docker-default" pid=1654 comm="dockerd" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.docker.dockerd

要解决此问题,请编辑 /etc/apparmor.d/docker 并添加到开头(但是,在 'profile docker-default .... {' 之后)以下行:

 signal,

然后重新加载 apparmor

 sudo systemctl reload apparmor

这至少在我的电脑上修复了它。

查看更多 https://manpages.ubuntu.com/manpages/ xenial/man5/apparmor.d.5.html 在信号部分下:

Example AppArmor signal rules:

       # Allow all signal access
       signal,

In my case it was also apparmor on Ubuntu 20.04 after upgrade from Bionic. By running dmesg I got error message:

[1113458.482007] audit: type=1400 audit(1672134271.112:1718): apparmor="DENIED" operation="signal" profile="docker-default" pid=1654 comm="dockerd" requested_mask="receive" denied_mask="receive" signal=kill peer="snap.docker.dockerd

To fix this please edit /etc/apparmor.d/docker and add to the beginning (however, after the 'profile docker-default .... {' ) the following line:

 signal,

Then reload apparmor

 sudo systemctl reload apparmor

This fixed it at least on my computer.

See more https://manpages.ubuntu.com/manpages/xenial/man5/apparmor.d.5.html under section signal:

Example AppArmor signal rules:

       # Allow all signal access
       signal,
千と千尋 2025-01-21 04:23:00

我也有类似的问题;原来我有两个docker安装。我按照 this 答案中的说明进行操作,但简而言之,docker 有两种安装,一种来自 apt< /code> 和另一个来自 snap 的内容。您需要从 snap 中删除那个,只保留 apt 中的那个。说明在链接中。

I had a similar issue; it turned out that I had two docker installations. I followed the instructions in this answer, but in a nutshell there are two installations for docker, one from apt and another from snap. You need to remove the one from snap, and just keep the one with apt. Instructions are in the link.

蓝色星空 2025-01-21 04:23:00

我找到了关于这个主题的中等帖子。我通常不会只遵循您在网上找到的任何命令。然而,这一次我迫切需要一个解决方案,而且它似乎奏效了。

https://medium.com/devops-technical-notes-and-manuals/how-to-solve-cannot-kill-docker-container-permission-denied-error-message-e3af7ccb7e29

TLDR:执行以下命令从 AppArmor 中删除未知解决了我的容器问题sudo aa-remove-unknown

I found medium post on this topic. I would not normally follow just any command you find online. However, this time I was desperate for a solution and it seemed to have worked.

https://medium.com/devops-technical-notes-and-manuals/how-to-solve-cannot-kill-docker-container-permission-denied-error-message-e3af7ccb7e29

TLDR: Executing the following command to remove the unknown from AppArmor solved my container problem sudo aa-remove-unknown

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文