Docker container cannot create files/directories on overlay2 without CAP_SYS_ADMIN due to xattr_permission EPERM #316

Kernel Version

6.6.89

Kernel Source Link (REQUIRED)

no

Droidspaces Version

6.5.5

Rooting Method

ksu

Device OEM & Model

realme

Android Version & ROM

16

Execution Mode

DAEMON

Networking Mode

NAT

Describe the Bug

When running a default Docker container (without --cap-add SYS_ADMIN), creating files or directories inside the container fails. The kernel xattr_permission() returns -1 (-EPERM), causing vfs_setxattr_locked to fail. Adding --cap-add SYS_ADMIN works around the issue.

This appears to be related to overlay2 storage driver and extended attributes (xattr) requiring CAP_SYS_ADMIN inside the container.
Environment

· OS: Debian 13 (Trixie) (please confirm with cat /etc/os-release)
· Docker version: (output of docker version)
· Kernel version: (output of uname -a)
· Storage driver: overlay2 (confirmed by /var/lib/docker/overlay2/... path)
· Container image: ubuntu:latest
· Docker run command:

docker run --rm -it --entrypoint bash --name t1 ubuntu

Steps to Reproduce

1. Install Docker CE on Debian 13.
2. Run:

   docker run --rm -it --entrypoint bash --name t1 ubuntu

3. Inside the container, try to create a directory or file:

   mkdir /root/testdir
   touch /root/testfile

   (or any operation that triggers xattr setting, e.g., installing packages)

Expected Behavior

Files and directories should be created successfully without requiring CAP_SYS_ADMIN.

Actual Behavior

Creation fails with permission error. Kernel log or strace shows:

xattr_permission() returns -1 (-EPERM)
vfs_setxattr_locked() fails

Typical error message:

mkdir: cannot create directory '/root/testdir': Operation not permitted

or

setfattr: /root/testdir: Operation not permitted

Workarounds

· Adding --cap-add SYS_ADMIN resolves the issue:

docker run --rm -it --cap-add SYS_ADMIN --entrypoint bash --name t1 ubuntu

· Using --privileged also works but is not recommended.
· Mounting a volume (-v /host/path:/container/path) may avoid the problem because the volume uses the host filesystem instead of overlay2.

Logs / Screenshots

No response

Required Acknowledgments

• I have verified this is not a duplicate issue.
• I am using a kernel compiled strictly according to Droidspaces' official documentation.
• I am NOT using a kernel with 69+ random configs, CRC nukes, or a broken ABI.
• I have confirmed this issue persists in both Daemon and Direct modes.
• I admit that I am a clown for checking this box, confirming I have NOT read these rules.
• I admit I did zero research, didn't ask my AI waifu for a fix, and am dropping this here because I'm 100% sure the fault lies with Droidspaces.