"Operation not permitted" when jlink --output refer outside WSL

[betanzos]

Windows build number: Microsoft Windows [Version 10.0.18363.657]
Dist: Ubuntu 18.04.4 LTS

$ jlink --add-modules java.base --output /mnt/d/jre-image
Error: java.io.UncheckedIOException: java.nio.file.FileSystemException: /mnt/d/jre-image/bin/java: Operation not permitted

Apparently generated JRE image work fine and it size is the same as if I export it withing WSL file system, but in this case I don't get the error.

This work fine:
$ jlink --add-modules java.base --output ~/jre-image

Logs lxcore-logs.zip

[therealkenc]

In principle would need to see the strace(1) log with the EPERM, but likely variation #1398 or similar.

First thing to try is move everything off /mnt/d and into /home/you and see if that helps. If it doesn't, give WSL2 shot.

[Biswa96]

What is the output of mount command? Any strace output.

[betanzos]

First thing to try is move everything off and into and see if that helps. If it doesn't, give WSL2 shot./mnt/d /home/you

@therealkenc, in my initial description I say:

Apparently generated JRE image work fine and it size is the same as if I export it withing WSL file system, but in this case I don't get the error.

This work fine:
$ jlink --add-modules java.base --output ~/jre-image

So, if --output refer inside WSL file system (i.e. /home/betanzos) the command exit witout error.

[betanzos]

@therealkenc @Biswa96 here the strace log strace.zip

[therealkenc]

Thanks. That strace is not threaded, and as a result the log does not contain an EPERM to examine. [Or at least in principle examine.]

$ strace -f -o jlink.strace jlink --add-modules java.base --output /mnt/d/jre-image

Look for the EPERM.

I suspect in this case you'll probably find the same behavior in WSL2 9p (/mnt/d). Work-around is to operate in $HOME as you surmised from the start.

[betanzos]

Apologize, I am not very familiar with Linux. Here the new strace log generated with your command.

I suspect in this case you'll probably find the same behavior in WSL2 9p (/mnt/d).

Right now I cant join to Insider program, so I cant try WLS2.

Work-around is to operate in $HOME as you surmised from the start.

I know it and I have no problems to do it,but I found it strange not to be able to do something so "simple". That's why I opened the issue.

[therealkenc]

Thanks for the strace. This is the only EPERM I could see in there:

17169 clock_gettime(CLOCK_MONOTONIC,  <unfinished ...>
17158 chmod("/mnt/d/jre-image/bin/java", 0777 <unfinished ...>
17169 <... clock_gettime resumed> {tv_sec=877459, tv_nsec=859443900}) = 0
17158 <... chmod resumed> )             = -1 EPERM (Operation not permitted)

I can't tell for sure that's the fail because there isn't an accompanying "Operation not permitted" string. [That's not on you. Commonly you'd expect to see the error written to stderr.]

The Error: java.io.UncheckedIOException string is in there clear enough:

17169 gettid( <unfinished ...>
17170 <... futex resumed> )             = 0
17158 write(1, "Error: java.io.UncheckedIOExcept"..., 123 <unfinished ...>
17169 <... gettid resumed> )            = 17169

The EPERM fail is close to the end though, so that's probably it.

Try this for the data point:

$ touch /mnt/d/jre-image/bin/foo
$ chmod 777 /mnt/d/jre-image/bin/foo

Can you also try this (pursuing a hunch):

$ jlink --add-modules java.base --output /mnt/d/jre-image 2> jlink.err

Do you still see the "Operation not permitted", or does it get redirected into jlink.err.

[betanzos]

You are right, that's the problem: EPERM

I think the process fail when trying to change generated files permissions to 777. Is interesting the fact that all files are created with 777 permissions, so in this case chmod is redundant. Because of this the JRE under /mnt/d/jre-image work fine without any problem.

Try this for the data point:

$ touch /mnt/d/jre-image/bin/foo
$ chmod 777 /mnt/d/jre-image/bin/foo

touch work fine. File is created with 777 permissions and root:root as owner.

chmod fail: chmod: changing permissions of '/mnt/d/jre-image/bin/foo': Operation not permitted. This is because sudo is required (if I use sudo work fine). Is there any restriction to manage file permissions on Windows File System?

Can you also try this (pursuing a hunch):

$ jlink --add-modules java.base --output /mnt/d/jre-image 2> jlink.err

After do this jlink.err is empty.

[therealkenc]

Alright. Create a file /etc/wsl.conf (with sudo vi or sudo nano) that contains the following:

[automount]
options=metadata,uid=1000,gid=1000

Your mounts should now be user you, not root.

Chances better than not this will address the EPERM.

[betanzos]

No work for me after create the file /etc/wsl.conf and reload my distro many times

[betanzos]

If I do unmount/mount manually with that options work fine

sudo umount /mnt/d
sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000

[betanzos]

I found a solution in this closed issue #3994 .

Thanks for filing! In 1903 we made a change to keep distribuitons running for a while after your last client exits. You could have hit this in 1809, but the Windows was very small. You'd also hit this if you launched something in the background (keeping the distro alive).

Work-around is to manually terminate your distro after modifying /etc/wsl.conf using:
wsl.exe --terminate <distro_name>

So, in order to load changes made to file /etc/wsl.conf is necesary execute following command in CMD or Power Shell:

$ wsl --terminate Ubuntu

[therealkenc]

Sorry I didn't warn you about the wsl.exe --terminate (newspeak wsl.exe --shutdown).

This was a long walk to "enable metadata", which is a common pitfall. I should have guessed from the get-go (maybe I'm getting slow). Happy you're unblocked.

[betanzos]

Don't worry you have helped me a lot.

Thanks!