When a docker container is stopped within docker, it can't be deleted afterwards

[ghost]

GNS3 version 2.0.4dev1 on Darwin (64-bit) with Python 3.5.2 Qt 5.6.0 and PyQt 5.6, official GNS3 VM with latest 2.0.4dev1.

https://www.gns3.com/discussions/cannot-delete-ubuntu-docker-node

• Create a new project
• Add a docker container, that has persistent directories, e.g. ipterm, ubuntu, ...
• Start it
• stop it within docker (NOT by GNS3 stop), e.g. "exit" the bash
• delete that VM

You get an error message like "Internal server error http://192.168.1.99:3080/v2/compute/projects/d5450942-c737-48b3-94e6-6c2ba562896d/docker/nodes/33c86a81-074b-4785-8b0a-37c92716739b". The reason is, that the permissions of the persistent directories haven't be restored, so they are owned by root. Therefore GNS3 can't delete them.

Afterwards the node in the project is in an inconsistent state, you have close and then re-open the project, then start and stop the docker node by GNS3 to restore the permissions. Now the node can be deleted.

A similar issue arises, when you delete the whole project. The deletion is done, without any error message, but because of the permissions, there are some leftovers on the server.

I have the following ideas to make that more user friendly:

• check the permissions before trying to delete it. If the permissions are not OK, refuse to delete the node.
• delete with extended privileges, e.g. sudo
• move the node directory into a temporary space, e.g. <GNS3 projects path>/__deleted and afterwards delete it. If the deletion fails, don't report it as a failure. A cron job (with root permissions) should regularly cleanup this temporary directory.
• Use linux ACLs to give GNS3 access to the persistent directories independently from the normal permissions.

[julien-duponchelle]

The three solution at the end will not be possible because it will require too much permission and Linux distributions will complaint about that.

I think the only solution is when we want to delete a node with permission issues we start / stop it.

[ghost]

The move to a temporary directory needs no elevated permissions on GNS3 (both the node directory and the temp directory are owned by GNS3), only on the cleanup script.

The ACL solution needs no elevated privilege at all. The trick is, when the persistent directory is initially created, to additionally set an ACL, that allows gns3 access independently from the normal permissions (setfacl -dm u:<gns3 user>:rwx <directory>). At the time of the initial directory creation, the gns3 user is already it's owner, so the setfacl call needs no elevated privileges. But I agree, that this is a quite complex solution.

start / stop is fine as long the user doesn't do some extended stuff on startup. Maybe a special start with just a busybox shell is more efficient. When a whole project is deleted, quite some nodes might have to started / stopped.

[ghost]

Forget the ACL solution, that doesn't work always.

[julien-duponchelle]

The start / stop with a special script is a good idea

[julien-duponchelle]

The init script of the user should not have an impact because we will start/stop without waiting it