expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-22 07:11:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Permissions docm. for WSL

Browse Source
This commit is contained in:
Philip Sargent 2022-04-12 22:47:38 +03:00
parent a744a28823
commit 96938cc8cc
1 changed files with 23 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
handbook/computing/winlaptop.html
View File

@ -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:
<pre>
<tt>rsync -nazv --delete-after --prune-empty-dirs expo@expo.survex.com:expofiles/ expofiles</tt></pre>
<p>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.
<p>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.
<p>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.
<h3 id="permissions">Permissions, permissions..</h3>
<p>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.
<p>The recommended WSL procedure (Jan.2018) said to mount the drive using
<a href="https://devblogs.microsoft.com/commandline/chmod-chown-wsl-improvements/">a new 'metadata' setting</a>:
<pre><code>sudo umount /mnt/d
sudo mount -t drvfs D: /mnt/d -o metadata,uid=1000,gid=1000,umask=22,fmask=111</code></pre>
<p>This is probably why there is a difference between automatically-mounted drives (e.g. C:, /mnt/c) and plug-in drives:
"<em>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).</em>"
<p>And of course you will need to arrange that this happens automatically whenever you start WSL, so you will need to set
<a href="https://help.ubuntu.com/community/Fstab"><var>/etc/fstab</var></a>, so ensure that the relevant line says:
<pre><code>D: /mnt/d drvfs metadata,uid=1000,gid=1000,umask=22,fmask=11 0 0</code></pre>
<p>See also <a href="https://docs.microsoft.com/en-us/windows/wsl/file-permissions">File Permissions for WSL</a> (Dec. 2021).
<h3 id="bold">"Are you feeling lucky, punk"</h3>
<p>So here is the current wild frontier. Currently these are the ways to get a terminal window which you might expect to work: