From 96938cc8cc3e2692a5d22dce587b8c9d05a58067 Mon Sep 17 00:00:00 2001 From: Philip Sargent Date: Tue, 12 Apr 2022 22:47:38 +0300 Subject: [PATCH] Permissions docm. for WSL --- handbook/computing/winlaptop.html | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/handbook/computing/winlaptop.html b/handbook/computing/winlaptop.html index bd0c6aa88..16382d995 100644 --- a/handbook/computing/winlaptop.html +++ b/handbook/computing/winlaptop.html @@ -140,9 +140,31 @@ The generated key is in the current directory and you need to move them to ~/.ss Now finally you can use all the usual command line tools at yor wsl command line to communicate with the server with ssh, scp, rsync, such as: 
 rsync -nazv --delete-after --prune-empty-dirs expo@expo.survex.com:expofiles/ expofiles
-

But this only works with WSL1 not WSL2 ! Under WSL1 it doesn't matter if your /expofiles/ is mounted on the Linux filesystem, typically under /home/expo/expofiles, or whether it it in the NTFS filesystem mount for Linux as, e.g. /mnt/d/expofiles. Under WSL2 /mnt/d/expofiles fails, either with a permissions problem or, if you try sudo rsync.. , with a ssh authentication failure (why? Given that we explicitly sate that we want to be user expo@ ?). Ghastly anyway. +

But this only works with WSL1 not WSL2 ! Under WSL1 it doesn't matter if your /expofiles/ is mounted on the Linux filesystem, +typically under /home/expo/expofiles, or whether it it in the NTFS filesystem mount for Linux as, +e.g. /mnt/d/expofiles. +Under WSL2 /mnt/d/expofiles fails, either with a permissions problem or, if you try sudo rsync.. , +with a ssh authentication failure (why? Given that we explicitly sate that we want to be user expo@ ?). Ghastly anyway. See next section, where the +same problem appears on WSL1.

All of which is really a bit ridiculous if all you want to do is to use rsync on a Windows machine to sort out some photos. +

Permissions, permissions..

+

Having happily used WSL1 in this manner for a couple of years, it was a rude awakening to try this with a new laptop with a small +hard-drive, so all the expo code was mounted on a plugged-in SD card. The problem of permissions that seemed to be a WSL2 issue reappeared with +a vengence on WSL1. +

The recommended WSL procedure (Jan.2018) said to mount the drive using +a new 'metadata' setting: +

sudo umount /mnt/d
+sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000,umask=22,fmask=111
+

This is probably why there is a difference between automatically-mounted drives (e.g. C:, /mnt/c) and plug-in drives: +"By default, WSL will set the uid and gid to the default user with drives that are auto-mounted during instance start. If you mount manually, you will +have to set these explicitly (the default user that gets created when WSL is first installed has a uid=1000 and gid=1000)." +

And of course you will need to arrange that this happens automatically whenever you start WSL, so you will need to set +/etc/fstab, so ensure that the relevant line says: +

D:           /mnt/d         drvfs   metadata,uid=1000,gid=1000,umask=22,fmask=11     0    0
+ +

See also File Permissions for WSL (Dec. 2021). +

"Are you feeling lucky, punk"

So here is the current wild frontier. Currently these are the ways to get a terminal window which you might expect to work: