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:
 <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: