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-private
znaleźć 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).
źródło
ecryptfs-add-passphrase --fnek
. Stwierdziłem, że zamiast tego musiałem użyć drugiego.sudo
, nawet jeśli o tym nie wspominają. tzn .: zamiastecryptfs-unwrap-passphrase /home/username/.ecryptfs/wrapped-passphrase
, dosudo ecryptfs-unwrap-passphrase /home/.ecryptfs/username/.ecryptfs/wrapped-passphrase
(zauważ również nieco inną ścieżkę, której użyłem).Filename Encryption Key (FNEK) Signature [XYZ]:
nie mam pojęcia, co to za podpis ... @ Rozwiązanie Martina ( askubuntu.com/a/679565/924202 ) zrobiło to dla mnie. :-)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ć
sudo
obu poleceń poniżej):źródło
sudo
jest wymagane również przy pierwszym poleceniu (ecryptfs-insert-wrapped-passphrase-into-keyring
), w przeciwnym razie pojawia się następujący błąd!Error: Unwrapping passphrase and inserting into the user session keyring failed [-5] Info: Check the system log for more information from libecryptfs
sudo ecryptfs-recover-private /BLAH/.Private
dla mnie drugie polecenie ( ) nadal nie działa. :(mount: /tmp/ecryptfs.aLkDeiWo: mount(2) system call failed: No such file or directory. ERROR: Failed to mount private data at [/tmp/ecryptfs.aLkDeiWo].
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 :)
źródło
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
źródło
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 parametry
ecryptfs-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
Jeśli umieścisz listę plików w katalogu domowym, masz następujące linki (przed moją korektą)
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:
Moim rozwiązaniem było ponowne połączenie ze ścieżką względną pliku .Private i .ecryptfs
Po można ręcznie zamontować katalog domowy ręcznie lub za pomocą
(będziesz potrzebować hasła MOUNT - seria 32 znaków)
źródło