Tar cannot change ownership

[ulidtko]

I use Google’s depot_tools to build the Dart SDK into an RPM. It works locally, but on CircleCI I get this:

...
________ running '/usr/bin/python sdk/build/linux/sysroot_scripts/install-sysroot.py --arch i386' in '/tmp/build/BUILD/dart-2.1.1'
Installing Debian Jessie i386 root image: /tmp/build/BUILD/dart-2.1.1/sdk/build/linux/debian_jessie_i386-sysroot
Downloading https://commondatastorage.googleapis.com/chrome-linux-sysroot/toolchain/7031a828c5dcedc937bbf375c42daab08ca6162f/debian_jessie_i386_sysroot.tgz
tar: ./var/lib/misc/Makefile: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./var/lib/misc: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./var/lib: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./var/log/speech-dispatcher: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./var/log: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./var: Cannot change ownership to uid 376730, gid 5000: Invalid argument
tar: ./etc/default/libnss-db: Cannot change ownership to uid 376730, gid 5000: Invalid argument
...

Quite similar to this (ignored) question by @nbuonin1 :

Tar can not change ownership

I’m trying to install OCaml’s llvm module with opam. The install fails when opam tries to un-tar llvm with this error for every file in the archive: /bin/tar: llvm-3.8.0.src/<all-files>: Cannot change ownership to uid 107418, gid 5000: Invalid argument For my environment, I’m using ubuntu:latest as my source Docker image. To verify that its an issue with CircleCI’s environment, I can perform the same install cleanly on the same Docker image locally. I suspect that the issue is because there…

Anything I’m missing? I don’t control the tar file, nor the unpacking command. The uid 376730 also looks strange to me (out of 16-bit range). Do I file an issue against depot_tools?

[drazisil]

I think that since --no-same-owner works, we may need to kick this to depot_tools

The issue is, I suspect, that each container gets a different UUID for root (for security), and the tool can’t handle that, as it tries to give it back to the id that owned it when it was saved.

Interested in other’s thoughts (posts no longer auto-close until marked solved)

[ulidtko]

Yes, @drazisil, you’ve set me on the right path with --no-same-owner. I found this config of someone where they used TAR_OPTIONS environment to inject this option, and it helps.

Sincerely thanks, your support appreciated.