search

cryfs / cryfs

Cryptographic filesystem for the cloud
https://www.cryfs.org
GNU Lesser General Public License v3.0
2.02k stars 155 forks source link

How to identify an invalid block #343

Open oregoni opened 4 years ago

oregoni commented 4 years ago

Expected Behavior

Normal mounting at mountpoint

Actual Behavior

Migrating file system for conflict resolution features. This can take a while... 0%[2020-05-15 08:39:21.054] [Log] [error] Crashed: This is not a valid block.

Assumed Solution

Removing invalid block and mounting without it. Is this an option?

Steps to Reproduce the Problem

  1. Update cryfs to 0.10
  2. Migrate data with interruption by a system suspend
  3. Mount at usual mount point

Specifications

smessmer commented 4 years ago

Sorry to hear this happened. Unfortunately, there are currently no tools to try and extract non-corrupted files from a corrupted file system. It should be possible in theory, but isn't implemented yet.

tweber-ill commented 4 years ago

I had a similar problem: A corrupted cryfs filesystem after upgrading from Ubuntu 18.04 to 20.04 and a migration of the cryfs KDE Vaults to the latest version.

As a quick hack, which worked for me and which SHOULD DEFINITELY NOT BE DONE GENERALLY, especially if you don't have any backups, cryfs could be forcefully convinced to mount the non-corrupt part of the filesystem again by changing line 73 in src/cryfs/impl/filesystem/fsblobstore/FsBlobStore.cpp from ASSERT(childBlob != none, "Couldn't load child blob"); to if(childBlob != none) so that it simply ignores the blob causing the problem still calls _migrate(...) in line 74 on all others instead of exiting completely.

physikant commented 1 year ago

Is there any way to find files containing invalid blocks in the meanwhile?

I am facing a similar issue as @oregoni after having had to restore my encrypted files from a cloud storage. At the moment I am not able to decrypt the data at all:

`CryFS Version 0.10.2

Password: Deriving encryption key (this can take some time)...done [2023-08-03 20:58:02.021] [Log] [error] Crashed: This is not a valid block.`

As the decrypted data is really important to me I would be very thankful for any help. I've tried @tweber-ill hint, without success, though.

I'm using KDE Neon with cryfs version 0.10.2, the original encryption was done with version 0.9.9 or so.

kiuverkaddiel commented 10 months ago

My laptop shutdown improperly by battery low. Now cryfs don't mount:

cryfs .local/share/plasma-vault/Work.enc/ Vaults/Work/ CryFS Version 0.10.2

Password: Deriving encryption key (this can take some time)...done [2023-12-13 01:35:57.809] [Log] [error] Crashed: This is not a valid block.

What can i do for skip the invalid files and mount the fs anyway. Thanks for any comment.

I'm using Kubuntu 22.04.

kiuverkaddiel commented 10 months ago

I had a similar problem: A corrupted cryfs filesystem after upgrading from Ubuntu 18.04 to 20.04 and a migration of the cryfs KDE Vaults to the latest version.

As a quick hack, which worked for me and which SHOULD DEFINITELY NOT BE DONE GENERALLY, especially if you don't have any backups, cryfs could be forcefully convinced to mount the non-corrupt part of the filesystem again by changing line 73 in src/cryfs/impl/filesystem/fsblobstore/FsBlobStore.cpp from ASSERT(childBlob != none, "Couldn't load child blob"); to if(childBlob != none) so that it simply ignores the blob causing the problem still calls _migrate(...) in line 74 on all others instead of exiting completely.

Is any way to do this from user interface? I think this is a solution for force cryfs to mount the fs. At least you recovery part of your data.