Jekyll: Operation not permitted @ apply2files

Question

I am using Windows 10's Linux subsystem where I installed Jekyll but when I run bundle exec jekyll serve it gives me:

jekyll 3.8.6 | Error: Operation not permitted @ apply2files - /mnt/e/Work/project/_site/images/banner.jpg

I know there are some incompatibilities with Windows and Linux permissions, because all my files are owned by root for some reason, but there is a fix to this issue?

I found an answer here https://scottdorman.blog/2019/02/27/running-jekyll-on-wsl/ where the author says I have to close and reopen the bash, but it doesn't work.

Obtain

Did you ever resolve this issue? – Stein

No. Unfortunately I've ended up using the native Windows installer instead of using the WSL. The native one works as expected. – Obtain

The awarded answer below I believe is the key. – Stein

Answer 1

These "operation not permitted" errors seem to be related to user rights or ownership.

I have seen strange errors on colleagues' MAC computers. The command ls -al showed that certain folders were owned by root.

If this applies to you, try to change/transfer ownership to your user with these commands:

• sudo chmod -R 777 /mnt/e/Work/project/
• sudo chown -R youruser /mnt/e/Work/project/

The difference between chmod and chown is simple:

• chmod changes modes
• chown changes ownership

Note: This is explained in detail on unixtutorial.org.

For the Windows Linux Subsystem, I have found this old blogpost devblogs.microsoft.com from January 2018:

How did permissions work in the past?
Prior to Build 17063, all files/folders list “root” as the owner and belonged to the group “root”. The permission bits on each file/folder was derived from Windows permissions–no write bit checked for Windows meant no write bit set in WSL.
Additionally, attempting to chmod or chown on a file/folder resulted in a no-op (they wouldn’t do anything!)

How do permissions work now?
For files that don’t have metadata, we apply the same approach as what is described in pre-17063 builds. But now, chmod/chown can assign metadata to the file or folder. Newly created files in WSL will be created with metadata by default and will respect the mount options you’ve set (discussed later) or the permissions you pass when executing a mkdir/open.

And, I have found this SO post: chmod WSL (Bash) doesn't work, which states that it's enough to unmount and re-mount the drive to make chmod and chown work (after the mentioned WSL update).

Ypres

When I execute ls -al it does show that root owns the files and folders. When I executed your command above it does not appear to assign owner to my user. – Stein

@Ypres Pre Command: sudo chown -R mike /mnt/c/workspace/github/github-pages-demo.github.io/ Post – Stein

Can you change the ownership of single files? – Ypres

@Ypres no I cannot – Stein

I revisited this today. It just worked. I assume that a combination of restarting my machine, plus restarting WSL, accomplished the same as the extra link above. – Stein

It's odd because I just checked out Jekyll sites where I never changed any permissions, and they all appear to be owned by my user instead of root, and they just work. A WSL quirk? Either way, I gained some valuable knowledge, so thank you. – Stein

Answer 2

As @Mike Cole mentioned above in the comments: If you are using wsl this can happen. I resolved this by restarting my machine and magically it works now.

Duero

Confirmed. Had this problem after installing fresh copy of Ubuntu 20.04 in WSL2. Files were listed as owned by root, but after rebooting Windows, they're now listed under my username – Soldierly

Answer 3

The problem

This error also occoured for me on WSL. But I'm happy to have found a fix that doesn't require me to manually chmod permissions into directories. The error is verbose enough to tell me its an issue with my chmod command not allowing me to do that, rather than something I should be doing for every single folder on my system each time I want to rbenv into it to work on something like Jekyll.

ion not permitted @ apply2files - /mnt/e/source/repos/work/ecs-saber/docs (Errno::EPERM)

Little research

EPERM is a validation check, a deep dive would reveal this is a safety feature that prevents you, even if you have access, from being able to do anyhting to file permissions with Ruby on directories / files that you are not a part of the group ownership on.

So how did I fix it?

I fixed it via adding WSL DrvFs speclines to my /etc/wsl.conf file (see: https://learn.microsoft.com/en-us/windows/wsl/wsl-config#wslconfig )

The rest of this document breaks down the steps.

---

1. Configure your WSL root account:

You should have a root password, because you won't have access to /etc, even with your user's sudo command, so first:

me@PRIVATE-PC:/mnt/c/Users/private$ sudo passwd
[sudo] password for me:
New password:
Retype new password:
passwd: password updated successfully

Now login as root

su -
Password:
Welcome to Ubuntu 20.04.5 LTS (GNU/Linux *.*.*.*-microsoft-standard-WSL2 x86_64)
...
This message is shown once a day. To disable it please create the
/root/.hushlogin file.
root@PRIVATE-PC:~# _

Now, good little admins should also harden their root accounts, but this isn't the scope of this answer. You can move forward for now, but you should go back and do this. I am obligated to tell you that about root access, anywhere, at any time (that includes at 3AM, Junior Devs, where the greatest mistakes happen with the root shell is when we are tired)

Put a string on your finger to harden root shell -- Circulation is important, don't actually do this physically, I need you to keep your fingers.

2. Apply /etc/wsl.conf change

Now that you are root, you can give the /etc partiiton the fix:

Write /etc/wsl.conf, just copy/paste on command line and press [enter]:

cat <<'EOF' > /etc/wsl.conf
[automount]
enabled = true
root = /mnt
options = "metadata,uid=1000,gid=1000,umask=022,case=off"
mountFsTab = false
EOF

Why umask=022 ?

Octal permissions to exclude (octal subtract) from files and directories. This produces a permission set of 0755 where your user has the ability to read, write, and execute, but your overlaying group and everyone can only read and execute.

3. Restarting without rebooting

Now, do a flip. (Simulate a restart of WSL) See: https://superuser.com/questions/1126721/rebooting-ubuntu-on-windows-without-rebooting-windows

I'll improve the solution presented by saying you don't have to reboot, if you know the right commands.

root@PRIVATE-PC:~# exit
logout
me@PRIVATE-PC:/mnt/c/Users/private$ exit
ohmyPOSH> wsl -d Ubuntu-20.04 --shutdown
ohmyPOSH> wsl -t Ubuntu-20.04
ohmyPOSH> Restart-Service LxssManager

Just count to ten in your head (Microsoft's stated rule is 8 seconds), get up have a stretch, then log back in via Windows Terminal PowerShell tab:

ohmyPOSH> wsl -d Ubuntu-20.04 -u me

Check the permissions on your jekyll project folder:

me@PRIVATE-PC:/mnt/c/users/me$ cd /mnt/e/source/repos/work/ecs-saber/docs
me@PRIVATE-PC:/mnt/e/source/repos/work/ecs-saber/docs$ ls -lah

drwxr-xr-x 1 me me 4.0K Sep  1 04:20 .
drwxr-xr-x 1 me me 4.0K Sep  1 03:49 ..
-rwxr-xr-x 1 me me   56 Sep  1 04:20 .gitignore
-rwxr-xr-x 1 me me    6 Sep  1 03:50 .ruby-version
-rwxr-xr-x 1 me me  419 Sep  1 04:20 404.html
-rwxr-xr-x 1 me me 2.1K Sep  1 04:20 _config.yml
drwxr-xr-x 1 me me 4.0K Sep  1 04:20 _posts

And now they are owned by your user with permissions set to a much less unnerving 0755! You no longer have to do this for every single directory, in fact, if you check others, like your user folder:

me@PRIVATE-PC:/mnt/c/users/me$ ls -lah

drwxr-xr-x 1 me me  512 Sep  1 03:59  .
drwxr-xr-x 1 me me  512 Aug 28 04:45  ..
drwxr-xr-x 1 me me  512 Aug 30 07:08  .aws
drwxr-xr-x 1 me me  512 Aug 30 07:08  .azure
drwxr-xr-x 1 me me  512 Aug 30 10:03  .cache
drwxr-xr-x 1 me me  512 Aug 30 09:53  .conda
-rwxr-xr-x 1 me me    4 Aug 31 07:32  .condarc
drwxr-xr-x 1 me me  512 Aug 28 12:19  .docker
...

You'll have a lot of the same.

Onward

me@PRIVATE-PC:/mnt/e/source/repos/work/ecs-saber/docs$ jekyll new . --force
Running bundle install in /mnt/e/source/repos/work/ecs-saber/docs...
  Bundler: Fetching gem metadata from https://rubygems.org/............
  Bundler: Resolving dependencies...
  Bundler: Using public_suffix 5.0.0
  Bundler: Using bundler 2.3.21
  Bundler: Using colorator 1.1.0
  Bundler: Using concurrent-ruby 1.1.10
  Bundler: Using eventmachine 1.2.7
  Bundler: Using http_parser.rb 0.8.0
  Bundler: Using ffi 1.15.5
  Bundler: Using forwardable-extended 2.6.0
  Bundler: Using rexml 3.2.5
  Bundler: Using rb-fsevent 0.11.2
  Bundler: Using liquid 4.0.3
  Bundler: Using mercenary 0.4.0
  Bundler: Using rouge 3.30.0
  Bundler: Using unicode-display_width 1.8.0
  Bundler: Using safe_yaml 1.0.5
  Bundler: Using addressable 2.8.1
  Bundler: Using i18n 1.12.0
  Bundler: Using sassc 2.4.0
  Bundler: Using rb-inotify 0.10.1
  Bundler: Using pathutil 0.16.2
  Bundler: Using em-websocket 0.5.3
  Bundler: Using terminal-table 2.0.0
  Bundler: Using jekyll-sass-converter 2.2.0
  Bundler: Using kramdown 2.4.0
  Bundler: Using listen 3.7.1
  Bundler: Using kramdown-parser-gfm 1.1.0
  Bundler: Using jekyll-watch 2.2.1
  Bundler: Using jekyll 4.2.2
  Bundler: Fetching jekyll-seo-tag 2.8.0
  Bundler: Fetching jekyll-feed 0.16.0
  Bundler: Installing jekyll-feed 0.16.0
  Bundler: Installing jekyll-seo-tag 2.8.0
  Bundler: Fetching minima 2.5.1
  Bundler: Installing minima 2.5.1
  Bundler: Bundle complete! 7 Gemfile dependencies, 31 gems now installed.
  Bundler: Use `bundle info [gemname]` to see where a bundled gem is installed.
New jekyll site installed in /mnt/e/source/repos/work/ecs-saber/docs

🎉 No more EPERM validation failures.

Pedroza