Description of problem: When running a mock build on x86_64 for a 32-bit mock, it fails to unpack the tarball while setting utime. This occurs for all files in the tarball: /usr/bin/tar: pikepdf-1.6.5/setup.py: Cannot utime: Operation not permitted It can also be reproduced by just running `touch` on any random file in a mock shell. Version-Release number of selected component (if applicable): mock-1.4.21-1.fc30.noarch Steps to Reproduce: 1. mock -r fedora-rawhide-i386 --shell 2. touch ~/test Actual results: touch: setting times of '/builddir/test': Operation not permitted Expected results: File should be created and timestamp of file should be current.
confirmed on my side as well. Are there any workarounds?
Additional observation: if I enter a 32-bit mock shell and try to untar a source package, the source is untarred, but it has UID and GID 1000, and not root. Manually setting the owner back to root does not solve much, since any testing of a build of any software package will fail horribly as soon as it tries to create some directory or file.
> Are there any workarounds? Use `--old-chroot`. This is https://bugzilla.redhat.com/show_bug.cgi?id=1770154
Hello, This also affects all the COPR builds that are using fedora-rawhide-i386. Error: >/usr/bin/tar -xof - >/usr/bin/tar: Cannot utime: Operation not permitted >/usr/bin/tar: Exiting with failure status due to previous errors >ERROR: Command failed: > # /usr/bin/systemd-nspawn -q -M 0260de8336204609ba3a02c8ab68e0ac -D /var/lib/mock/1116847-fedora-rawhide-i386-1574565038.101060/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.zmfh2uta:/etc/resolv.conf --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=en_US.UTF-8 -u mockbuild bash --login -c /usr/bin/rpmbuild -bb --target i686 --nodeps /builddir/build/SPECS/mesa.spec There is more than half a month since this issue appeared. Any solution for this?
This has been fixed in seccomp.
This is not yet fixed, see bug 1804415 (opened independently). I'll leave this closed so as to not have multiple bug reports open.