Problems in the filesystem in a container with ubuntu 22.04 inside an host with ubuntu 20.04

General
1

PROBLEM IN SHORT

I touch a file, then delete it and the deletion fails:

$ touch jjj
$ rm jjj
rm: cannot remove 'jjj': Operation not permitted

DETAILS

  • It only happens in a non-privileged user. With root it works well.
  • It only happens when the container is ubuntu:22.04, if I run another container with ubuntu:20.04 it works well.
  • The host is ubuntu:20.04
  • At home I also have the very same combination (host 20.04 and container 22.04) and it works well.

The main difference between my home and the server with the problem is that:

home => docker version (client+engine) => 24.0.2
failing-server => docker version (client+engine) => 19.03.12

HOW TO REPEAT

In the host with ubuntu 20.04 and docker 19.03.12 I do run those tests (screenshot):

image
image1016×408 21.1 KB

AT HOME

image
image743×207 10.8 KB

TEMPTED TO…

I’m tempted to upgrade the docker engine from v19 to v24 but I have some production things like 45 containers and 63 volumes.

image

Containers, bah… destroyable…

I’m affraid of missing “all the data” set in the volumes if I do an upgrade.

QUESTIONS

  1. Can this error be due the docker version?
  2. If yes, can I do some kind of “hot-upgrade” so I don’t loose volumes, nets, images, and containers without --rm?

Thanks in advance.

2

I have seen a similar issue in Docker Desktop before. If I remember correctly, it was on Mac or Windows and the reason was that a folder was mounted from the host machine into the virtual machine to a container which means Docker has to do some “magic” to translate the filesystem operations to operations on the host and it didn’t always worked perfectly. I guess the answer is no, but are you using Docker Desktop on any of the mentions involved in the tests?

The fact that it happens only with Ubuntu 22.04 containers makes it weirder though. All I can think of is that the lowlevel filesystem operations in the two different distributions are different somehow.

One more thing that comes to my mind. It wouldn’t be the first that a Linux distribution in a container is not compatible with the Docker version. If I’m not mistaken, it happened with the apt commands as well because of an incompatbible system call with Docker. That was the day when I relized that Docker handles system calls first. I also remember that there was something on Docker Hub as well, but I don’t remember what.

3

Thanks for the reply. That happens in “native linux”, not Windows.

I guess it’s merely a bug in v19, solved at some point in between v19 and v24 (v24 works like a charm in respect to this issue).

Question reminds alive: How can I do a “hot-upgrade” from v19 to v24 without being affraid of any risk about loosing volumes, nets, images, and containers?