ecryptfs-utils does not handle changing password

Start by retrieving the mount passphrase:
 $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD

If any errors occur, you're probably not giving the correct LOGIN_PASSWORD. When you do, it will just display the MOUNT_PASSPHRASE on standard out.

To access your data, you always can manually mount as root with the MOUNT_PASSPHRASE:
 $ sudo mount -t ecryptfs ~/.Private /mnt
   (3) passphrase
   MOUNT_PASSPHRASE
   (1) aes
   (1) 16 bytes
   (n) no plaintext passthrough
   (yes) proceed with the mount as root
   (yes) add to signature cache

Or, to mount as yourself, you can manually insert the MOUNT_PASSPHRASE into your kernel keyring and then mount with:
 $ ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
 $ mount.ecryptfs_private
 $ ls ~/Private

To fix this for your next boot, you may need to:
 $ ecryptfs_rewrap_passphrase ~/.ecryptfs/wrapped-passphrase PREVIOUS_LOGIN_PASSWORD NEW_LOGIN_PASSWORD

The PAM password change module has been hooked by pam_ecryptfs, so all of this should have happen automatically. Can you tell me any more about how you worked did this, in case there's an actual bug here?

:-Dustin

A related bug might be Bug #272232. The PAM password change stack currently has a bug where a password change might be reported as "successful" even though it wasn't. Note that pam_ecryptfs will ONLY rewrap the passphrase if the password change ACTUALLY succeeds, regardless of what the output messages might be.

:-Dustin

I'm having the same issue, following your instructions:

 $ ecryptfs_insert_wrapped_passphrase_into_keyring ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
 $ mount.ecryptfs_private

I am able to mount it manually, but none of this happens at start-up.

I have a fingerprint reader set up (pam_fprint.so), so my common-auth looks like this:
#
# /etc/pam.d/common-auth - authentication settings common to all services
#
# This file is included from other service-specific PAM config files,
# and should contain a list of the authentication modules that define
# the central authentication scheme for use on the system
# (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the
# traditional Unix authentication mechanisms.
#
# As of pam 1.0.1-5, this file is managed by pam-auth-update by default.
# To take advantage of this, it is recommended that you configure any
# local modules either before or after the default block, and use
# pam-auth-update to manage selection of other modules. See
# pam-auth-update(8) for details.

auth sufficient pam_fprint.so

# here are the per-package modules (the "Primary" block)
auth [success=1 default=ignore] pam_unix.so nullok_secure
# here's the fallback if no module succeeds
auth requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth required pam_permit.so
# and here are more per-package modules (the "Additional" block)
auth optional pam_ecryptfs.so unwrap
# end of pam-auth-update config

Would this break it? Note that I don't type in my password to log-in, I just use the fingerprint reader.

Unable to read salt value from user's .ecryptfsrc file; using default
Error attempting to unwrap passphrase and insert into the user session
keyring; rc = [-5]. Check the system log for more information from
libecryptfs.
What does this mean?

On Tue, Oct 14, 2008 at 5:00 PM, Dustin Kirkland
<email address hidden>wrote:

> Start by retrieving the mount passphrase:
> $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
>
> If any errors occur, you're probably not giving the correct
> LOGIN_PASSWORD. When you do, it will just display the MOUNT_PASSPHRASE
> on standard out.
>
> To access your data, you always can manually mount as root with the
> MOUNT_PASSPHRASE:
> $ sudo mount -t ecryptfs ~/.Private /mnt
> (3) passphrase
> MOUNT_PASSPHRASE
> (1) aes
> (1) 16 bytes
> (n) no plaintext passthrough
> (yes) proceed with the mount as root
> (yes) add to signature cache
>
> Or, to mount as yourself, you can manually insert the MOUNT_PASSPHRASE into
> your kernel keyring and then mount with:
> $ ecryptfs_insert_wrapped_passphrase_into_keyring
> ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
> $ mount.ecryptfs_private
> $ ls ~/Private
>
> To fix this for your next boot, you may need to:
> $ ecryptfs_rewrap_passphrase ~/.ecryptfs/wrapped-passphrase
> PREVIOUS_LOGIN_PASSWORD NEW_LOGIN_PASSWORD
>
> The PAM password change module has been hooked by pam_ecryptfs, so all
> of this should have happen automatically. Can you tell me any more
> about how you worked did this, in case there's an actual bug here?
>
> :-Dustin
>
> ** Changed in: ecryptfs-utils (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: ecryptfs
> Status: New => Incomplete
>
> --
> ecryptfs-utils does not handle changing password
> https://bugs.launchpad.net/bugs/283477
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Oct 14 20:24:01 ion ecryptfs-insert-wrapped-passphrase-into-keyring: Error
attempting to parse .ecryptfsrc file; rc = [-5]
Oct 14 20:24:02 ion ecryptfs-insert-wrapped-passphrase-into-keyring:
Incorrect wrapping key for file [/home/defcon/.ecryptfs/wrapped-passphrase]
Oct 14 20:24:02 ion ecryptfs-insert-wrapped-passphrase-into-keyring: Error
attempting to unwrap passphrase from file
[/home/defcon/.ecryptfs/wrapped-passphrase]; rc = [-5]

On Tue, Oct 14, 2008 at 8:22 PM, defcon <email address hidden> wrote:

> Unable to read salt value from user's .ecryptfsrc file; using default
> Error attempting to unwrap passphrase and insert into the user session
> keyring; rc = [-5]. Check the system log for more information from
> libecryptfs.
> What does this mean?
>
>
>
> On Tue, Oct 14, 2008 at 5:00 PM, Dustin Kirkland <
> <email address hidden>> wrote:
>
>> Start by retrieving the mount passphrase:
>> $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
>> LOGIN_PASSWORD
>>
>> If any errors occur, you're probably not giving the correct
>> LOGIN_PASSWORD. When you do, it will just display the MOUNT_PASSPHRASE
>> on standard out.
>>
>> To access your data, you always can manually mount as root with the
>> MOUNT_PASSPHRASE:
>> $ sudo mount -t ecryptfs ~/.Private /mnt
>> (3) passphrase
>> MOUNT_PASSPHRASE
>> (1) aes
>> (1) 16 bytes
>> (n) no plaintext passthrough
>> (yes) proceed with the mount as root
>> (yes) add to signature cache
>>
>> Or, to mount as yourself, you can manually insert the MOUNT_PASSPHRASE
>> into your kernel keyring and then mount with:
>> $ ecryptfs_insert_wrapped_passphrase_into_keyring
>> ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
>> $ mount.ecryptfs_private
>> $ ls ~/Private
>>
>> To fix this for your next boot, you may need to:
>> $ ecryptfs_rewrap_passphrase ~/.ecryptfs/wrapped-passphrase
>> PREVIOUS_LOGIN_PASSWORD NEW_LOGIN_PASSWORD
>>
>> The PAM password change module has been hooked by pam_ecryptfs, so all
>> of this should have happen automatically. Can you tell me any more
>> about how you worked did this, in case there's an actual bug here?
>>
>> :-Dustin
>>
>> ** Changed in: ecryptfs-utils (Ubuntu)
>> Status: New => Incomplete
>>
>> ** Changed in: ecryptfs
>> Status: New => Incomplete
>>
>> --
>> ecryptfs-utils does not handle changing password
>> https://bugs.launchpad.net/bugs/283477
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

im also getting:
Input/output error
when trying to open files in /mnt where it mounted

On Tue, Oct 14, 2008 at 5:00 PM, Dustin Kirkland
<email address hidden>wrote:

> Start by retrieving the mount passphrase:
> $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
>
> If any errors occur, you're probably not giving the correct
> LOGIN_PASSWORD. When you do, it will just display the MOUNT_PASSPHRASE
> on standard out.
>
> To access your data, you always can manually mount as root with the
> MOUNT_PASSPHRASE:
> $ sudo mount -t ecryptfs ~/.Private /mnt
> (3) passphrase
> MOUNT_PASSPHRASE
> (1) aes
> (1) 16 bytes
> (n) no plaintext passthrough
> (yes) proceed with the mount as root
> (yes) add to signature cache
>
> Or, to mount as yourself, you can manually insert the MOUNT_PASSPHRASE into
> your kernel keyring and then mount with:
> $ ecryptfs_insert_wrapped_passphrase_into_keyring
> ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
> $ mount.ecryptfs_private
> $ ls ~/Private
>
> To fix this for your next boot, you may need to:
> $ ecryptfs_rewrap_passphrase ~/.ecryptfs/wrapped-passphrase
> PREVIOUS_LOGIN_PASSWORD NEW_LOGIN_PASSWORD
>
> The PAM password change module has been hooked by pam_ecryptfs, so all
> of this should have happen automatically. Can you tell me any more
> about how you worked did this, in case there's an actual bug here?
>
> :-Dustin
>
> ** Changed in: ecryptfs-utils (Ubuntu)
> Status: New => Incomplete
>
> ** Changed in: ecryptfs
> Status: New => Incomplete
>
> --
> ecryptfs-utils does not handle changing password
> https://bugs.launchpad.net/bugs/283477
> You received this bug notification because you are a direct subscriber
> of the bug.
>

omg this bug really sucks I cant even copy my data what do I do next, thanks
for the help

On Tue, Oct 14, 2008 at 8:37 PM, defcon <email address hidden> wrote:

> im also getting:
> Input/output error
> when trying to open files in /mnt where it mounted
>
> On Tue, Oct 14, 2008 at 5:00 PM, Dustin Kirkland <
> <email address hidden>> wrote:
>
>> Start by retrieving the mount passphrase:
>> $ ecryptfs-unwrap-passphrase ~/.ecryptfs/wrapped-passphrase
>> LOGIN_PASSWORD
>>
>> If any errors occur, you're probably not giving the correct
>> LOGIN_PASSWORD. When you do, it will just display the MOUNT_PASSPHRASE
>> on standard out.
>>
>> To access your data, you always can manually mount as root with the
>> MOUNT_PASSPHRASE:
>> $ sudo mount -t ecryptfs ~/.Private /mnt
>> (3) passphrase
>> MOUNT_PASSPHRASE
>> (1) aes
>> (1) 16 bytes
>> (n) no plaintext passthrough
>> (yes) proceed with the mount as root
>> (yes) add to signature cache
>>
>> Or, to mount as yourself, you can manually insert the MOUNT_PASSPHRASE
>> into your kernel keyring and then mount with:
>> $ ecryptfs_insert_wrapped_passphrase_into_keyring
>> ~/.ecryptfs/wrapped-passphrase LOGIN_PASSWORD
>> $ mount.ecryptfs_private
>> $ ls ~/Private
>>
>> To fix this for your next boot, you may need to:
>> $ ecryptfs_rewrap_passphrase ~/.ecryptfs/wrapped-passphrase
>> PREVIOUS_LOGIN_PASSWORD NEW_LOGIN_PASSWORD
>>
>> The PAM password change module has been hooked by pam_ecryptfs, so all
>> of this should have happen automatically. Can you tell me any more
>> about how you worked did this, in case there's an actual bug here?
>>
>> :-Dustin
>>
>> ** Changed in: ecryptfs-utils (Ubuntu)
>> Status: New => Incomplete
>>
>> ** Changed in: ecryptfs
>> Status: New => Incomplete
>>
>> --
>> ecryptfs-utils does not handle changing password
>> https://bugs.launchpad.net/bugs/283477
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

Oct 14 20:44:23 ion kernel: [ 2013.334164] Could not find key with description: [6060c848761e2613]
Oct 14 20:44:23 ion kernel: [ 2013.334177] process_request_key_err: No key
Oct 14 20:44:23 ion kernel: [ 2013.334182] ecryptfs_parse_packet_set: Could not find a usable authentication token
Oct 14 20:44:23 ion kernel: [ 2013.334191] Valid eCryptfs headers not found in file header region or xattr region
Oct 14 20:44:23 ion kernel: [ 2013.334197] Either the lower file is not in a valid eCryptfs format, or the key could not be retrieved. Plaintext passthrough mode is not enabled; returning -EIO

I can ls the files, just not access/copy/move them

@kelvie-

Fingerprint readers are not supported yet, but should be. See Bug #255799, and post your comments there.

:-Dustin

Your problems begin here:
 * Error attempting to unwrap passphrase and insert into the user session keyring; rc = [-5]

If ecryptfs cannot unwrap the passphrase, it cannot perform the mount and you will not be able to read your data.

Looking at the system log, it says:
 * ion ecryptfs-insert-wrapped-passphrase-into-keyring: Incorrect wrapping key for file [/home/defcon/.ecryptfs/wrapped-passphrase]

This means that you're trying to unwrap the mount passphrase with the wrong login password. You might try both your current, and your new password, or any other that you might have used.

When you can unwrap your mount passphrase successfully, you should be able to perform the mount.

In the case that you are not able to unwrap your passphrase, you should have recorded it somewhere. If you setup your Encrypted Private Directory in the installer, there was an installation screen that said:

   There is no way to recover this passphrase if you lose it. To avoid
    losing data, you should normally write down the passphrase and keep it
    in a safe place separate from this computer.
    .
    Your new encryption passphrase is as follows:
    ${PASSPHRASE}
    Please write this down and store it separately from this computer.

Or, if you used 'ecryptfs-setup-private' to setup your ~/Private directory, it said:

    ************************************************************************
    YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
    ${PASSPHRASE}
    THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
    ************************************************************************

:-Dustin

ok I just moved .ecryptfs and .Private to another directory to reinstall
ecryptfs private
ecryptfs-setup-private
defcon@ion:~$ ecryptfs-setup-private
Enter your login passphrase:
Enter your login passphrase (again):
Enter your mount passphrase [leave blank to generate one]:
Enter your mount passphrase (again):

************************************************************************
YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
************************************************************************

Unable to read salt value from user's .ecryptfsrc file; using default
ERROR: Could not add passphrase to the current keyring
defcon@ion:~$

On Wed, Oct 15, 2008 at 7:52 AM, Dustin Kirkland
<email address hidden>wrote:

> Your problems begin here:
> * Error attempting to unwrap passphrase and insert into the user session
> keyring; rc = [-5]
>
> If ecryptfs cannot unwrap the passphrase, it cannot perform the mount
> and you will not be able to read your data.
>
> Looking at the system log, it says:
> * ion ecryptfs-insert-wrapped-passphrase-into-keyring: Incorrect wrapping
> key for file [/home/defcon/.ecryptfs/wrapped-passphrase]
>
> This means that you're trying to unwrap the mount passphrase with the
> wrong login password. You might try both your current, and your new
> password, or any other that you might have used.
>
> When you can unwrap your mount passphrase successfully, you should be
> able to perform the mount.
>
> In the case that you are not able to unwrap your passphrase, you should
> have recorded it somewhere. If you setup your Encrypted Private Directory
> in the installer, there was an installation screen that said:
>
> There is no way to recover this passphrase if you lose it. To avoid
> losing data, you should normally write down the passphrase and keep it
> in a safe place separate from this computer.
> .
> Your new encryption passphrase is as follows:
> ${PASSPHRASE}
> Please write this down and store it separately from this computer.
>
> Or, if you used 'ecryptfs-setup-private' to setup your ~/Private
> directory, it said:
>
> ************************************************************************
> YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
> ${PASSPHRASE}
> THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
> ************************************************************************
>
>
> :-Dustin
>
> --
> ecryptfs-utils does not handle changing password
> https://bugs.launchpad.net/bugs/283477
> You received this bug notification because you are a direct subscriber
> of the bug.
>

all I did was change my password in the terminal for my login and rebooted,
now I cannot access my data, now I cant even recreate ecryptfs private...
This is upsetting

On Wed, Oct 15, 2008 at 4:35 PM, defcon <email address hidden> wrote:

> ok I just moved .ecryptfs and .Private to another directory to reinstall
> ecryptfs private
> ecryptfs-setup-private
> defcon@ion:~$ ecryptfs-setup-private
> Enter your login passphrase:
> Enter your login passphrase (again):
> Enter your mount passphrase [leave blank to generate one]:
> Enter your mount passphrase (again):
>
> ************************************************************************
> YOU SHOULD RECORD YOUR MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
> THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
> ************************************************************************
>
> Unable to read salt value from user's .ecryptfsrc file; using default
> ERROR: Could not add passphrase to the current keyring
> defcon@ion:~$
>
>
> On Wed, Oct 15, 2008 at 7:52 AM, Dustin Kirkland <
> <email address hidden>> wrote:
>
>> Your problems begin here:
>> * Error attempting to unwrap passphrase and insert into the user session
>> keyring; rc = [-5]
>>
>> If ecryptfs cannot unwrap the passphrase, it cannot perform the mount
>> and you will not be able to read your data.
>>
>> Looking at the system log, it says:
>> * ion ecryptfs-insert-wrapped-passphrase-into-keyring: Incorrect wrapping
>> key for file [/home/defcon/.ecryptfs/wrapped-passphrase]
>>
>> This means that you're trying to unwrap the mount passphrase with the
>> wrong login password. You might try both your current, and your new
>> password, or any other that you might have used.
>>
>> When you can unwrap your mount passphrase successfully, you should be
>> able to perform the mount.
>>
>> In the case that you are not able to unwrap your passphrase, you should
>> have recorded it somewhere. If you setup your Encrypted Private Directory
>> in the installer, there was an installation screen that said:
>>
>> There is no way to recover this passphrase if you lose it. To avoid
>> losing data, you should normally write down the passphrase and keep it
>> in a safe place separate from this computer.
>> .
>> Your new encryption passphrase is as follows:
>> ${PASSPHRASE}
>> Please write this down and store it separately from this computer.
>>
>> Or, if you used 'ecryptfs-setup-private' to setup your ~/Private
>> directory, it said:
>>
>>
>> ************************************************************************
>> YOU SHOULD RECORD THIS MOUNT PASSPHRASE AND STORE IN A SAFE LOCATION:
>> ${PASSPHRASE}
>> THIS WILL BE REQUIRED IF YOU NEED TO RECOVER YOUR DATA AT A LATER TIME.
>>
>> ************************************************************************
>>
>>
>> :-Dustin
>>
>> --
>> ecryptfs-utils does not handle changing password
>> https://bugs.launchpad.net/bugs/283477
>> You received this bug notification because you are a direct subscriber
>> of the bug.
>>
>
>

Are you on a completely up-to-date (apt-get update && apt-get upgrade)
Ubuntu Intrepid Ibex system?

:-Dustin

The code generating the error message you see looks like this:

    response=`ecryptfs-add-passphrase "$MOUNTPASS"`
    if [ $? -ne 0 ]; then
            error "Could not add passphrase to the current keyring"
    fi

Also, note the following from the manpage:
       Be sure to properly escape your parameters according to your
shell's special character nuances, and also surround the parameters by
double quotes, if necessary.

Are you using a mount passphrase of your choosing, or are you having
ecryptfs choose a random one for you?

:-Dustin

Dustin,

I'm also having priblem with the encryptfs-add-passphrase "$MOUNTPASS" line, so that i also get the following sequence of errors:

unable to read salt value from user's .ecryptfsrc file; using default
ERROR: Could not add passphrase to the current keyring

this happened after i was fooling around somewhat irresponsibly with ecryptfs-utils, decided to wipe the encrypted directory & .ecryptfs and then recreate them; as kyle describes, after you do something like this it's no longer possible to use the setup-private tool. moreover i'm really not sure where to find the keyring that pam is adding to -- i looked through my gnome keyrings and don't see the ecryptfs password anywhere in them. because of this it's hard for me to figure out what to do next, or what values need to be reset where...

i'm not sure this belongs in the same bug report as the original issue, but it seems to me to be a usability issue -- that the setup is easy to break and hard to fix, largely because the way it works isn't really documented.

thanks, matt

Matt-

Please open a new bug, and let's discuss there. This one is overloaded ;-)

:-Dustin

Matt, et al-

I added this, to answer how to start over clean:
 * https://answers.launchpad.net/ubuntu/+source/ecryptfs-utils/+question/48636

:-Dustin

I have tested password changing thoroughly over the course of this past week, and it seems to work in every case I can throw at it.

I'm marking this 'Fix Released'. Please reopen if you have a specific case you can reproduce on an up-to-date Intrepid.

Thanks!
:-Dustin

I have exactly the same problem as the reporter of this problem (running Xubuntu 8.10 with the latest updates).
I did the following:

1) Changed password using the "Users Settings" dialog
2) Rebooted
3) Logged in as the same user with the new password
4) Discovered that there is no directory ~/Private

When I tried to mount it manually, that is by running "mount.ecryptfs_private",
I got the folowing error:

keyctl_search: Required key not available

The only way I have been able to get into the ~/Private directory is by changing the password back to what it was originally.

eboy

PS In my opinion this is a bug with utmost priority, because it concerns data loss (at least as perceived by the average user) in the stable Xubuntu distribution.

Problem also seen on a fresh 9.10 with ecryptfs-utils 81-0ubuntu3.
Password changed via command-line 'passwd'.

/var/log/auth.log

Nov 26 22:50:32 machine passwd[7196]: pam_unix(passwd:chauthtok): password changed for bob
Nov 26 22:50:32 machine gnome-keyring-daemon[7199]: Couldn't unlock login keyring with provided password
Nov 26 22:50:32 machine gnome-keyring-daemon[7199]: Failed to unlock login on startup
Nov 26 22:50:32 machine passwd[7196]: gkr-pam: couldn't change password for 'login' keyring: 1
Nov 26 22:50:33 machine passwd[7203]: Incorrect wrapping key for file [/home/bob/.ecryptfs/wrapped-passphrase]
Nov 26 22:50:33 machine passwd[7203]: Error attempting to unwrap passphrase; rc = [-5]

As explained in http://ecryptfs.sourceforge.net/ecryptfs-pam-doc.txt this case should be handled whithout any problems.

I changed my user's passphrase for Ubuntu Server 15.10 to a 65+ character passphrase. Now I cannot save files that my user has permission to access and root must be used.

Log errors:

/var/log/auth.log

Apr 17 21:23:47 user sshd[18527]: pam_ecryptfs: Error adding passphrase key token to user session keyring; rc = [-5]
Apr 17 21:24:01 user sudo: Error attempting to unwrap passphrase from file [/home/user/.ecryptfs/wrapped-passphrase]; rc = [-5]
Apr 17 22:22:12 user sshd[19924]: Error attempting to unwrap passphrase from file [/home/user/.ecryptfs/wrapped-passphrase]; rc = [-5]

I attempted to recover:

sudo ecryptfs-recover-private /home/.ecryptfs/user/.Private

Printed error:

INFO: Found [/home/.ecryptfs/user/.Private].
Try to recover this directory? [Y/n]: y
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] y
INFO: Enter your LOGIN passphrase...
Passphrase:
Passphrase is too long. Use at most 64 characters long passphrase.
Usage:

ecryptfs-insert-wrapped-passphrase-into-keyring [file]
or
printf "%s" "wrapping passphrase" | ecryptfs-insert-wrapped-passphrase-into-keyring [file] -

ERROR: The key required to access this private data is not available.

Log error:

Apr 17 22:30:52 user ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to unwrap passphrase from file [/home/.ecryptfs/user/.Private/../.ecryptfs/wrapped-passphrase]; rc = [-5]

Limiting passphrases to 64 characters is not legitimate.

Same issue here. KDE's screen lock had crashed, so I dropped to the command line. I fat fingered my password into the user field after getting it wrong initially, so the first thing I did once I got a shell was to change my password.

I then rebooted, upon which I got:

Jul 31 08:02:01 void ecryptfs-insert-wrapped-passphrase-into-keyring: Incorrect wrapping key for file [/home/reuben/.ecryptfs/wrapped-passphrase]
Jul 31 08:02:01 void ecryptfs-insert-wrapped-passphrase-into-keyring: Error attempting to unwrap passphrase from file [/home/reuben/.ecryptfs/wrapped-passphrase]; rc = [-5]
Jul 31 08:05:01 void CRON[4528]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jul 31 08:05:04 void sudo: pam_ecryptfs: Passphrase file wrapped
Jul 31 08:05:04 void sudo: Incorrect wrapping key for file [/home/reuben/.ecryptfs/wrapped-passphrase]
Jul 31 08:05:04 void sudo: Error attempting to unwrap passphrase from file [/home/reuben/.ecryptfs/wrapped-passphrase]; rc = [-5]
Jul 31 08:05:04 void sudo: pam_ecryptfs: Error adding passphrase key token to user session keyring; rc = [-5]

I then changed my password back to what it was, rebooted, and this time it was able to wrap the key.