Try stepping through the ecryptfs-recover-private script yourself? It's just a bash script, you can copy & paste relevant lines into a terminal, replacing variables with your actual files.
You can also copy the ecryptfs-recover-private script and modify it, adding some extra echo lines to see what variables are before mounting, echo lines to be run, etc. (I'm certain there's a bash setting to display every line before it's run, but can't remember it right now.)
Maybe the ecryptfs-insert-wrapped-passphrase-into-keyring or the .ecryptfs/Private.sig signatures aren't matching, though the script checks for that.... but your output inserts one key sig, and tries mounting with a different sig.
At least you could run mount with -v for a little more feedback and to verify that the folders and sigs are correct.
There's also a bug, I thought just in mount.ecryptfs but maybe showing up here, where the fnek & fekek sigs get switched somehow.
Or, maybe some files have been corrupted. Any fsck news, or a current backup may be required. Also /var/log/syslog could have even more info.
Best Answer
No, this is the recommended thing to do. Bonus points for using a
UUID=/etc/fstabentry rather than the less precise/dev/sdxNnotation.As with anything, there are pros and cons. For one thing, if the home partition is going to be accessed by different installs, it is important that the user accounts and numeric user ids match across those installs. This is likely to be the case if you create a single user account during installation. On the other hand, if there are several users involved, it may be a complicated process to reproduce the same user ids across the installs. When managing partitions, it may not be obvious which
/homedirectories go with which installations, so the potential for human error is greater than with a single/partition per install.