Input/output errors with some files

[deb75]

Hi,

Sometimes, when I want to move or copy some files stored on cryfs, I get to some point one input/output error.

The error is reproducible, it happens only with some files, usually bigger than 100M, it always happen at the same point. It just says "input/output error"

It is quite embarrassing because, I just cannot move the encrypted file or copy it to another location, it does not depend on the other location.

Sometimes also, when I want to remove one file, it says it failed whereas the file has indeed disappeared (seems actually removed).

The cryfs container is itself contained in a ext4 luks partition, I do not know if this could be an issue.

Do you know what is going on ?

Hopefully, I can still read and modify the encrpted files, but how could I copy them to another location ?

Thanks in advance for your help.

Regards

[felleb]

Hello,
quite similar problem here. I/O-errors with some files. The problem itself differs: some files can't be opened, others not copied/moved. Only message is: »Input-/output error.«; no mor information is given.

Corrupted files stay corrupt, even when copied outside of the cryfs container. The file size doesn't seem to matter (files < 1 M also got corrupted).

It is frustrating to see my files getting corrupted because of the use of cryfs.

My system:

• CryFS 0.9.7 on recent Arch Linux
• encrypted data on top of a ext4 luks encrypted drive

Any help is very appreciated!
Regards,

[smessmer]

Hello,

there's two known scenarios how files can get corrupted

1. The cryfs process is killed while writing (i.e. without a proper unmount), or the computer is stopped without a proper shutdown
2. The hard drive runs out of disk space, which causes cryfs writes to fail

The syslog might help you figure out what happened.
Once a block is corrupted, you won't be able to read it anymore unfortunately. You can still read uncorrupted files and copy them somewhere else, and you also might be able to read other parts of the same file, since these parts are stored in a different, hopefully uncorrupted block.

[Apromixately]

So how do I clean up this situation? I currently get this:

00:53 $ ls mnttmp/
ls: cannot access 'mnttmp/MAILS': Input/output error
ls: cannot access 'mnttmp/STUFF': Input/output error
ls: cannot access 'mnttmp/EBOOKS': Input/output error
ADMIN EBOOKS STUFF MAILS NOTES PAPERS

[tendant]

Hello,

I ran into a similar issue, disk ran out of space when copying files to a mounted cryfs directory.

The problem I am facing is that none of the copied files showed up in mounted directory. However there are a lot encrypted blocks in cryfs directory.

The question is how to clean up those unused encrypted blcoks?

Thanks,

[frapell]

I just found a complete folder inside my cryfs to be corrupted like this... I have no idea when it got corrupted, I just found out when I needed the critical information that is inside...

I have accesed files inside this folder at some point, so I am 100% sure the space didn't fill up nor the cryfs process was killed while the folder was created... could it be that at some point I copied a file inside this folder, and somhow that corrupted the whole folder? Is there any way I could recover some files from this folder? or is everything lost forever? :(

Any idea when or if these corruption issues are going to be solved? the sole idea of having an encrypted folder is to store critical information for which you wouldn't have backups lying around, and making sure that information is not corrupted at any time sounds to me to be requirement number one, above the encryption itself...

[smessmer]

There are 2-3 known scenarios when CryFS can cause a corruption. (1) when the hard disk gets full and CryFS can't finish a write operation and (2) when the CryFS process gets killed in the middle of a write. Both can be solved by auditing write paths and making sure that the file system is never, not even temporarily, left in an inconsistent state. This is planned to be fixed soon, probably in 0.10.3. There's a potential but unconfirmed third issue where people report that upgrading a 0.9.x file system to 0.10.x leaves the file system in a corrupted state. I was never able to reproduce this and am not sure if they started the migration with an already corrupted file system or if the migration caused it. Since CryFS tends to store sensitive data, I haven't been successful yet in getting somebody to send me a data sample for such a file system so I could analyze it.

…

On June 8, 2020 7:41:12 AM Franco Pellegrini ***@***.***> wrote: I just found a complete folder inside my cryfs to be corrupted like this... I have no idea when it got corrupted, I just found out when I needed the critical information that is inside... I have accesed files inside this folder at some point, so I am 100% sure the space didn't fill up nor the cryfs process was killed while the folder was created... could it be that at some point I copied a file inside this folder, and somhow that corrupted the whole folder? Is there any way I could recover some files from this folder? or is everything lost forever? :( Any idea when or if these corruption issues are going to be solved? the sole idea of having an encrypted folder is to store critical information for which you wouldn't have backups lying around, and making sure that information is not corrupted at any time sounds to me to be requirement number one, above the encryption itself... — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[frapell]

@smessmer Hey, thank you for your response, I am on version 0.9.9 over here...

As per the scenarios, yes, I read the whole thread and was aware of them, however, as I mention, the folder was not corrupt and got corrupted at some point... I can understand a specific file being corrupt if the process is killed or the space fills up, but my question is, how can a complete folder become corrupted?

As I mention in my comment, mine was a folder that was perfectly fine...

encrypted_folder
|
|____ folder-a
|____|______document1.pdf
|____|______document2.pdf

Now, if one of the described scenarios happened when I was copying document3.pdf inside folder-a, I can understand that specific file being corrupt, however, in my case, folder-a is completely corrupt and I cannot even access documents that were perfectly fine at some point... Can you imagine one of these scenarios causing this? because if so, this is even more dangerous than I imagined...

[smessmer]

Yes, if CryFS gets killed while writing the folder entry (i.e. the list of files contained in the folder), then this would happen. The files would still be intact and there, but not accessible anymore because there's no valid folder pointing to them anymore. It should be possible to write tools that recover the files from such a situation, but those tools don't exist yez.

…

On June 22, 2020 5:26:00 AM Franco Pellegrini ***@***.***> wrote: @smessmer Hey, thank you for your response, I am on version 0.9.9 over here... As per the scenarios, yes, I read the whole thread and was aware of them, however, as I mention, the folder was not corrupt and got corrupted at some point... I can understand a specific file being corrupt if the process is killed or the space fills up, but my question is, how can a complete folder become corrupted? As I mention in my comment, mine was a folder that was perfectly fine... encrypted_folder | |____ folder-a |____|______document1.pdf |____|______document2.pdf Now, if one of the described scenarios happened when I was copying document3.pdf inside folder-a, I can understand that specific file being corrupt, however, in my case, folder-a is completely corrupt and I cannot even access documents that were perfectly fine at some point... Can you imagine one of these scenarios causing this? because if so, this is even more dangerous than I imagined... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[madbolter]

So, seriously, this is a deal-breaking problem! We now have many corrupted folders. We can't delete or update files. We can't remove the folders. We now have hundreds of gigs of "junk" data and no way to clean up the mess. Yes, the system was non-gracefully stopped, but IN THE REAL WORLD that happens! Why isn't cryfs robust enough to cope with that. Even Truecrypt BITD could cope with any "catastrophic" way that the filesystem could go out from under the process.

We're hosed and, apparently, with NO way to fix the problem. This sort of thing means that cryfs is just not ready for prime-time, because an issue this fundamental should never have been allowed to go into production.

[chlarsen]

Dear All,
An incredibly helpful exchange of experiences, though with rather discouraging outcome! Similar situation here: I experimentally deployed cryfs to encrypt an external USB hard drive, which I disconnected whilst files where in transit to simulate an accidental interruption of the encryption process. The external drive's cryfs-encrypted folder was well and truly hosed. This essentially means that cryfs does not keep a journal and is therefore well prone to lose your data. I therefore fully, though sadly, agree with @madbolter that cryfs is most definitely not fit for real-world use.
Nevertheless, I definitely appreciate all the efforts that has gone into this endeavour, but it cannot yet be safely used in the real world.

[bonafideduck]

Hi, adding to the possible symptoms. On Mac, when I tried moving a folder within the same cryfs, I got this corruption. Now I have folders that are listed as corrupted. I at least was able to move them.

@smessmer mentions that this is potentially fixed in 0.10.3, but I don't currently see that label. Any estimate on when this will be released?

---

And to those that have corrupted file systems and call this a deal-breaking problem. Good news, your backups of this critical data will have an uncorrupted file system you can extract this from.