I had a slight misunderstanding when I looked at the code previously. The copy up is of the parent directory, which makes sense because it needs to modify one of the dirents in that directory. Which by extension means that every ancestor of the dirent being unlinked needs to be copied up.
So the problem is not the owner of the inode which is the target of the unlink, but those of the ancestor directories. The tmpfs mount in the user ns cannot contain uids not mapped into the user ns, which is why the copy up fails. Since the directory will hang around after the unlink finishes, we don't want to change its ownership, but a directory with that ownership cannot exist in the tmpfs mount. The problem may indeed be intractable then. Is this breaking some real- world use case? Note that even if we could do the copy up, I'm not sure that we should. Generally speaking we don't want overlayfs to allow the user to create objects in the upperdir that the mounter of the overlayfs filesystem could not have created by other means. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1617388 Title: When using overlayfs with kernel 4.4, some files cannot be deleted. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1617388/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
