Looks like we're (fairly consistently) hitting cleanup errors from arm64 and cgroup2. In both cases, Jenkins is complaining about files from TestBuildUserNamespaceValidateCapabilitiesAreV2;

Both arm64 and cgroup2 jobs in Jenkins are running on Jenkins agent with Kernel 5.11 (also see #42892), so it seems there's a relation with that update of the agents / kernel.

https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/398/

Also:   java.nio.file.AccessDeniedException: /home/ubuntu/workspace/moby_PR-42835/bundles/test-integration/TestBuildUserNamespaceValidateCapabilitiesAreV2/de3b5140cc048/root/overlay2/9b312dec55e10fe243a5e0422a7f9375c0cc2880d41696ac19fd6d9c191f1f56-init/work/work

https://ci-next.docker.com/public/job/moby/job/PR-42835/19/execution/node/420/

Also:   java.nio.file.AccessDeniedException: /home/ubuntu/workspace/moby_PR-42835/bundles/test-integration/TestBuildUserNamespaceValidateCapabilitiesAreV2/d4b91bdaf46b5/root/165536.165536/overlay2/d6050e82750d178c5151ec1427a44ce8352d9aa6e9843d61483e0f54b4a3125f-init/work/work

Interesting case is that in the arm64 case, the path looks to be a rootless / remapped path (root/165536.165536), whereas in the overlay2 case, the path does not have the remapped user.

I guess that could be explained because the test starts to separate daemons; one rootless, and one not;

Wondering if one of those daemons is not succesfully killed, and therefore causing the permission denied