problem z ecryptfs-recovery-private: nie powiodło się montowanie (2)

Jestem w trakcie przenoszenia mojego systemu operacyjnego i danych z jednego dysku na drugi na tym samym komputerze. (Mam ładny, nowy dysk SSD.) Mój stary katalog domowy zawierał zaszyfrowany podkatalog i chciałbym uzyskać dostęp do zaszyfrowanego katalogu z mojej nowej instalacji. Próbuję użyć ecryptfs-recover-private. Wystąpił jednak następujący błąd.

$ 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].

Napotykam ten sam problem, jeśli pozwalam ecryptfs-recover-privateznaleźć katalog samodzielnie lub jeśli odmawiam hasło logowania, ale zamiast tego używam hasła mount.

Myśli?

(Zdaję sobie sprawę, że na tej stronie jest kilka podobnych pytań, ale żadne z nich nie wydaje się w pełni obejmować mojej sytuacji).

Więc to proste polecenie ecryptfs-recover-privateokazało się zawodne. Żadna z powyższych metod nie działała dla mnie, próbując przejść z ecryptfs do kontenera LUKS .

To, co zadziałało, to ręczna metoda opisana na wiki społeczności Ubuntu

Szczegółowo:

# 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

• wybierz 3 (użyj typu klucza hasła i użyj odzyskanego hasła, czyli unwrapped-passsphrase)
• wybierz aes (użyj szyfru aes)
• wybierz 16 (użyj 16-bajtowego klucza)
• włącz przekazywanie tekstu jawnego: n
• włącz szyfrowanie plików: y

Nie jestem pewien, dlaczego tak się dzieje - być może zepsucie breloka jądra podczas korzystania z tego samego hasła LOGIN w nowej konfiguracji, jak w tej, którą próbujesz odzyskać.

To powiedziawszy, dodanie zawiniętego hasła do pliku kluczy jądra przed próbą odzyskania systemu plików działa (pamiętaj, aby użyć sudoobu poleceń poniżej):

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

Obecnie używam testów Debiana i ostatnio potrzebowałem odzyskać plik z kopii zapasowej mojego zaszyfrowanego folderu .Private. Kopia zapasowa jest przechowywana na moim serwerze NAS. Wystąpił ten sam problem co ty. Ręczne wstawienie zapakowanego hasła nie pomogło i ręczne zamontowanie systemu plików cifs (z mojego NAS) przez rootowanie zamiast tworzenia montowania jako mój główny użytkownik (aby zapobiec właściwym konfliktom i tym podobne) również nie pomogło.

Jednak po zwykłym ponownym uruchomieniu systemu mogłem bezpośrednio użyć polecenia ecryptfs-recovery-private, aby zamontować folder .Private, który sam był umieszczony w systemie plików cifs.

Chociaż nie wyjaśnia to, co się dzieje źle, i jest to jedna z bardziej frustrujących wskazówek, które można uzyskać jako użytkownik systemu Linux:

uruchom ponownie system i spróbuj ponownie :)

Miałem podobne błędy po zmianie nazwy poprzedniej (oryginalnej) nazwy użytkownika POSIX na old_user (i), a następnie utworzyłem nowego użytkownika o oryginalnej nazwie (poprzedniej nazwy użytkownika).

Aby móc zamontować zaszyfrowany katalog domowy ze starego użytkownika, musiałem przerobić dowiązania symbolik dla .encryptfs i .Private w jego folderze (tak jak to zrobili po / home / original_name /).

Następnie następujące polecenie zamontowało stary dom bez żadnego problemu. / usr / bin / ecryptfs-recovery-private /home/old_user/.Private

Spędziłem godziny na tym problemie, nie rozumiejąc, dlaczego te proste polecenia nie działały. Znalazłem, że wprowadzają w błąd linki w ... / home / .ecryptfs i ... / home / .ecryptfs /username/.ecryptfs.

EDYCJA : należy potwierdzić następujące rozwiązanie. Ponowne połączenie może nie być obowiązkowe, ale podane parametryecryptfs-recover-private mogą być źródłem problemu.

Moim rozwiązaniem było ponowne połączenie ze ścieżką względną pliku .Private i .ecryptfs w /home/.ecryptfs/

Opracować:

W moim przypadku użytkownik domowy, którego chciałem przeczytać, był w katalogu / mnt / sda5 / home, a użytkownik był facetem

    $ cd /mnt/sda5/home 

    $ ls -lag .ecryptfs/guy/
        drwxr-xr-x  4 guy    4096  .
        drwxr-xr-x  3 root   4096  ..
        drwx------ 16 guy    4096  .Private
        drwx------  2 guy    4096  .ecryptfs


    $ ls -lag .ecryptfs/guy/.ecryptfs/
        drwx------ 2 guy 4096 Jan 1 00:12 .
        drwxr-xr-x 4 guy 4096 Jan 1 00:11 ..
        -rw------- 1 guy   13 Jan 1 00:11 Private.mnt
        -rw------- 1 guy   34 Jan 1 00:11 Private.sig
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-mount
        -rw-r--r-- 1 guy    0 Jan 1 00:11 auto-umount
        -rw------- 1 guy   58 Jan 1 00:12 wrapped-passphrase

    #This were the data are stored

Jeśli umieścisz listę plików w katalogu domowym, masz następujące linki (przed moją korektą)

    $ ls -lag guy/
   lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private  -> /home/guy/.Private
   lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> /home/guy/.ecryptfs

więc pliki łączą się z bieżącym / home i użytkownikiem, a nie z tymi, które próbujesz odczytać, myląc ciebie i polecenia montowania.

Po korekcie zaimplementowałem:

    $ ls -lag guy/
    dr-x------ 2 guy 4096 Jan 2 15:52 .
    drwxr-xr-x 6 root   4096 Jan 1 00:11 ..
    lrwxrwxrwx 1 root     28 Jan 2 15:52 .Private -> ../.ecryptfs/guy/.Private
    lrwxrwxrwx 1 root     29 Jan 2 15:49 .ecryptfs -> ../.ecryptfs/guy/.ecryptfs
    lrwxrwxrwx 1 guy   56 Jan 1 00:11 Access-Your-Private-Data.desktop -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.desktop
    lrwxrwxrwx 1 guy   52 Jan 1 00:11 README.txt -> /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt

Moim rozwiązaniem było ponowne połączenie ze ścieżką względną pliku .Private i .ecryptfs

    $ cd /mnt/sda5/home 
    $ cd guy
    $ sudo unlink .Private
    $ sudo unlink .ecryptfs 
    $ sudo ln -sr ../.ecryptfs/guy/.Private
    $ sudo ln -sr ../.ecryptfs/guy/.ecryptfs

Po można ręcznie zamontować katalog domowy ręcznie lub za pomocą

 cd /mnt/sda5/home 
 sudo ecryptfs-recover-private .ecryptfs/guy/.ecryptfs/.Private

(będziesz potrzebować hasła MOUNT - seria 32 znaków)