problema con ecryptfs-recover-private: mount (2) non riuscito

Sto trasferendo il mio sistema operativo e i dati da un'unità all'altra all'interno dello stesso computer. (Ho ottenuto un nuovo, bellissimo SSD.) La mia vecchia directory home conteneva una sottodirectory crittografata e mi piacerebbe accedere alla directory crittografata dalla mia nuova installazione. Sto provando a usare ecryptfs-recover-private. Tuttavia, ho riscontrato il seguente errore.

$ sudo ecryptfs-recover-private /BLAH/.Private
INFO: Found [.Private/].
Try to recover this directory? [Y/n]: 
INFO: Found your wrapped-passphrase
Do you know your LOGIN passphrase? [Y/n] 
INFO: Enter your LOGIN passphrase...
Passphrase: 
Inserted auth tok with sig [BLAH] into the user session keyring
mount: mount(2) failed: No such file or directory
ERROR: Failed to mount private data at [/tmp/ecryptfs.NcWkVmQ5].

Mi imbatto nello stesso problema se lascio ecryptfs-recover-privatetrovare la directory da solo o se dico di no alla passphrase di accesso ma uso invece la passphrase di mount.

Pensieri?

(Mi rendo conto che ci sono diverse domande simili su questo sito, ma nessuna sembra coprire abbastanza la mia situazione.)

Quindi questo semplice comando ecryptfs-recover-private, si è rivelato inaffidabile. Nessuno dei metohd sopra ha funzionato per me, cercando di passare dagli ecryptfs al contenitore LUKS .

Ciò che ha funzionato è stato il metodo manuale descritto nella wiki della comunità di Ubuntu

In dettaglio:

# sudo -i
# ecryptfs-add-passphrase --fnek 
Inserted auth tok with sig [aaaaaaaaaaaaa] into the user session keyring 
Inserted auth tok with sig [bbbbbbbbbbbbb] into the user session keyring  
# mkdir -p /mnt/new_mount_point  
# mount -t ecryptfs /mnt/old_mount_point/home/username/.Private /mnt/new_mount_point

• seleziona 3 (usa un tipo di chiave passphrase e usa la passphrase recuperata, nota anche come passphrase da scartare)
• seleziona aes (usa il codice aes)
• seleziona 16 (usa una chiave da 16 byte)
• abilita passthrough in chiaro: n
• abilita la crittografia del nome file: y

Non sono sicuro del motivo per cui ciò accade: forse un errore nel portachiavi del kernel quando si utilizza la stessa passphrase LOGIN sulla nuova configurazione di quella che si tenta di ripristinare.

Detto questo, aggiungendo la passphrase spostata nel portachiavi del kernel prima di provare a ripristinare il filesystem funziona (assicurarsi di utilizzare sudosu entrambi i comandi seguenti):

sudo ecryptfs-insert-wrapped-passphrase-into-keyring /BLAH/.ecryptfs/wrapped-passphrase
sudo ecryptfs-recover-private /BLAH/.Private

Attualmente sto usando il test debian e recentemente ho dovuto recuperare un file dal backup della mia cartella .Private crittografata. Il backup è archiviato sul mio NAS. Ho riscontrato lo stesso problema con te. L'inserimento manuale della passphrase spostata non ha aiutato e il montaggio manuale del filesystem cifs (dal mio NAS) per root invece di creare il mount come utente principale (per prevenire conflitti giusti e quant'altro) non ha aiutato.

Tuttavia, dopo aver chiaramente riavviato il mio sistema, ho potuto usare direttamente il comando ecryptfs-recover-private per montare la cartella .Private, che a sua volta si trovava sul filesystem cifs.

Anche se questo non spiega cosa non va ed è uno dei suggerimenti più frustranti che potresti ottenere come utente Linux:

riavviare il sistema e riprovare :)

Ho avuto errori simili dopo aver rinominato il nome utente POSIX (originale) precedente in old_user (e) e quindi creato un nuovo utente con il nome originale (nome utente precedente).

Per poter montare la directory home crittografata dal vecchio_utente, ho dovuto rifare i collegamenti symbolik per .encryptfs e .Private nella sua cartella (come avevano spostato in / home / nome_originale /).

Successivamente, il seguente comando ha montato la vecchia casa senza alcun problema. / usr / bin / ecryptfs-recover-private /home/old_user/.Private