[OnePlus 7 Pro Questions & Answers] LoganDark:
EDIT NOTICE: THIS DIDN'T WORK, DON'T MAKE IT WORSE BY TRYING

ORIGINAL POST IS BELOW

Alright. Well, I found a solution. That was quick.

The error is triggered by the backup containing a user that isn't present during the restore, I think. One solution is (theoretically) to create the missing user... another solution is to remove the missing user from the backup.

Turns out, backups are not so hard to modify, even in their compressed form. However, it is a little bit unintuitive at first.

You can't use the `tar` command to modify the backup, at all. TWRP's tar doesn't even support the --delete flag, nor does the BSD tar command (what ships with macOS). Even after installing GNU tar, it still refuses to work on a compressed archive (probably for the better).

You either need a Windows system with WinRAR/7zip (allows opening/modifying compressed files without extracting them), or a macOS/Linux system with FUSE and archivemount. If you're on Windows, you will have to manually search every single folder for 10 or 999 folders and delete every single one. If you're on macOS/Linux, the process is a bit more technical but also a bit more automated. And in both cases you will have to do this many times, and it can easily take half an hour or more and many restore attempts.

First and foremost, you need the recovery log to find out where the process failed. Every time it fails you will need to go to Advanced > Copy Log, copy them to the SD card, then use the flipping horrible Android File Transfer program to transfer the recovery.log to your PC, then use the cat/tail command or a text editor of your choice to read the log file.

Somewhere around the end of that file you will find something that looks like this:

==> extracting: //data/misc_de/10/ (mode 41771, directory)
Cannot find key for 10
error looking up proper e4crypt policy for '//data/misc_de/10/' - 1DE10
tar_extract_file(): failed to extract //data/misc_de/10/ !!!
I:Unable to extract tar archive '/data/media/0/TWRP/2020-11-08--22-06-46 PRE-RR/data.ext4.win003'

This contains all the info you need: the archive where the tar command gave up, and the file it gave up on.

Destroy that file with extreme prejudice.

Make a mount point with `mkdir mnt`, and mount the archive with `sudo archivemount data.ext4.win003 mnt`. (Of course, substitute data.ext4.win003 with the culprit archive file.)

If you're like me and have this problem with 10 folders, or 999 folders, you can find every single one of its kind with `sudo find mnt -name 10`. You can then use `sudo rm -rf` to delete every one of them. If you're brave, try `sudo find data -name 10 -exec sudo rm -rf \{\} \;`. I'm not responsible for any data losses incurred by using powerful commands that don't prompt you for confirmation.

Notice how I'm repeatedly using `sudo` for this: FUSE is kind of quirky and so is the kernel about multi-user filesystems. If you don't use sudo to mount the archive, then the user won't have permission to represent files it doesn't own, even if root is the one asking. You'll get weird "No such file or directory" errors for files and directories that are contained in parent directories' file listings. If you don't use sudo for the find or rm commands, you won't have permission to look inside folders or delete folders. Really, do everything with sudo because it's the only way to do this correctly.

Once you're done scrubbing the problem files away (be careful, do not use a file explorer of any kind, especially macOS's, which generally craps .DS_Store files all over your filesystem), unmount and save the archive with `sudo umount mnt`.

The next part is very important because recompressing files is not instant.

You will need to run `watch -n 1 du -hs data.ext4.win003` and WAIT.

Watch the file size slowly grow; only continue once it has stayed the exact same for at least one minute. Yes, it can definitely stop for 30 seconds at a time and then resume. You will need to give it time to recompress. It's also probably normal for the recompressed file to be about half the size of the initial file; that's just an artifact of TWRP not using very good compression to begin with. archivemount will create a backup of the archive with .orig appended, so you can try again if your backup ends up getting corrupted. (I just created an entirely separate copy of the backup to use archivemount on)

Of course, if you're on Windows you can skip all this and simply delete the problem file from WinRAR/7zip, and it'll be gone instantly and you can just proceed to copy the archive over to your device and retry the backup. You will have to do all the searching manually though, or perhaps you could try your luck with WSL. (Does WSL support FUSE?)

Expect this process to fail multiple times, but all at different points; whenever it fails at a different file, you know it got past the one you just removed. all you need to do is repeat this process over and over, slowly fixing your backup until it restores properly. This is what needs to be done if you can't reproduce the event that created that user in the first place. I'm sure if the user is important, it'll get created again.