vastie.blogg.se

1. Cannot utime operation not permitted install#
2. Cannot utime operation not permitted archive#
3. Cannot utime operation not permitted code#

I think this is because of the problem described by Dave Hay in this blog post. Tar: Exiting with failure status due to previous errors Tar: usr/local/bundle: Cannot change mode to rwxr-sr-x: Operation not permitted Tar: usr/local/bundle: Cannot utime: Operation not permitted Key: v1-bundle-īut when we come to restore the cache for the next job we get errors: Found a cache from build 45 at v1-bundle-37RyclRo4zIg9I2R_L+I72Po+eXbphREAXxknkNduy8=

Cannot utime operation not permitted install#

The usr/local/bundle directory has drwxrwsrwx permissions, so we can use a Circle 2.0 config.yml to bundle install and save the cache: - run: bundle install

Set via BUNDLE_SILENCE_ROOT_WARNING: true Set via BUNDLE_APP_CONFIG: "/usr/local/bundle" Settings are listed in order of priority. $ whoamiĪnd the default bundler options are: $ bundle config Lrwxrwxrwx 1 root staff 9 Jul 16 00:00 man -> share/manĭrwxrwsr-x 2 root staff 4096 Jul 16 00:00 sbinĭrwxrwsr-x 1 root staff 4096 Jul 17 03:16 shareĭrwxrwsr-x 2 root staff 4096 Jul 16 00:00 srcīut the build tasks are run as the circleci user. $ ls -Al /usr/localĭrwxrwsr-x 1 root staff 4096 Aug 11 00:06 binĭrwxrwsrwx 2 root staff 4096 Jul 21 08:36 bundleĭrwxrwsr-x 1 root staff 4096 Jul 17 07:54 etcĭrwxrwsr-x 2 root staff 4096 Jul 16 00:00 gamesĭrwxrwsr-x 1 root staff 4096 Jul 21 08:36 includeĭrwxrwsr-x 1 root staff 4096 Jul 21 08:36 lib The image already has a /usr/local/bundle directory pre-created by the root user. By default, the files are owned by root and not readable by somebody else.Using the Docker image circleci/ruby it’s impossible to restore a bundler cache saved to the default location of /usr/local/bundle. Set the file permission on the filesystem. In that case there is a possibility to use proper mount options. So either copy as root or change the permissions on target so that you have a write permission on media directory.Īs pointed out it's not possible to change permissions nor ownership on mounted NTFS filesystem. It seems to me that permissions are not correctly set.īut you can't create a file in a destination because the directory media is not writeable by you, only root can do that

chowning the folder to the current user makes tar fail silently so the installer can continue.

Cannot utime operation not permitted code#

Judging from the OP's own answer, it seems then that the installer checks tar's exit code and stops if an error was encountered.

Permissions are restored for both the folder and the files, and no error is thrown even though user2 ownership could not be restored. Here's what happens if the extraction is performed in a directory owned by user1 instead: $ tar xpvzf The files are however extracted, although owned by user1. Tar throws an error because it cannot change ownership and permissions for files owned by user2. : Cannot change mode to rwxrwxr-x: Operation not permitted

Cannot utime operation not permitted archive#

If we extract the archive in a directory owned by user2 with permissions 777, here's the outcome: $ tar xpvzf Let's say we are user1 and have created an archive with tar cvpzf. Update: Here's some more details about tar's behaviour.

Reference: read this informative Q&A on askubuntu:Įven if you use tar's -same-owner flag, you will still need to extract the files as root to preserve ownership. Question: Permissions cannot be restored for a tar