The folowing sycall is failing when called on a Travis-CI build machine.

        CLONE_FILES |
        CLONE_IO |
        CLONE_VM |
        CLONE_NEWNET |
        CLONE_NEWUTS |

This works when I run it on my machine, but inside the Docker container that
Travis creates it fails with EPERM. Can anyone suggest why this might be
happening? The clone(2) manpage lists possible reasons:

        or CLONE_NEWUTS was specified by an unprivileged process (process
        without CAP_SYS_ADMIN).

This shouldn't apply since I'm using CLONE_NEWUSER

EPERM   CLONE_PID was specified by a process other than process 0. (This error
        occurs only on Linux 2.5.15 and earlier.)

Doesn't apply.

EPERM   CLONE_NEWUSER was specified in flags, but either the effective user ID
        or the effective group ID of the caller does not have a mapping in the
        parent namespace (see user_namespaces(7)).

Again, this shouldn't apply. The process creating the namespace has a valid
(not-nobody) uid and gid.

EPERM   (since Linux 3.9) CLONE_NEWUSER was specified in flags and the caller
        is in a chroot environment (i.e., the caller's root directory does not
        match the root directory of the mount namespace in which it resides).

Possibly this one? The docker container shouldn't be aware that it's running in
a chroot though. Calling mount inside the container lists:

    overlay on / type overlay (rw,relatime,...)

Which indicates that it's living inside its own mount namespace with its own
root directory.

So I'm confused. Does anyone have any suggestions for why else this might be
failing or thngs I could try to debug it? Is there a way to get more than just
an eror code out of linux? Are there reasons for giving that error code that
aren't listed in the man page?

Any help would be greatly appreciated.
 - Andrew

Attachment: signature.asc
Description: Digital signature

lxc-users mailing list

Reply via email to