Open StarShine1A opened 1 month ago
A VeraCrypt bug is unlikely to cause the main partition to disappear from the File Manager as VeraCrypt primarily interacts with the encrypted volume. The behavior described suggests a more systemic issue.
I see few possible reasons:
can you please share kernel logs (dmesg) and system logs (journalctl ) around the time the issue happens? This can help understand what happened.
Journal CTL
I'd like to note that the device was always plugged in through the entire files moving operation
The issue, again, only appears while moving files to a Veracrypt encrypted volume. Veracrypt freezes when hitting "dismount" for a while, then it dismounts and once done any other volume of the same disc gets forcefully ejected, and the device even if unplugged then replugged is not recognized by the computer. Rebooting solves it but then when you remount your veracrypt partition, all the data you supposed have been written on it have somehow vanished as if they never were.
Trying to copy the same folder that wasn't copied to the place it was supposed to be copied to lands you this error permanently:
Your errors seem very similar to what are displayed here with the same description of symptoms: https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)
USB Attached Storage (UAS) is now commonly found for USB 3.0 storage devices. However, this sometimes causes issues with non-compliant adapters requiring it to be disabled. Issues with having UAS enabled include slow write performance, or having the device randomly drop off until the USB connection is reset.
Though I've never had the issue myself so don't know whether disabling such feature would help.
Your errors seem very similar to what are displayed here with the same description of symptoms: https://leo.leung.xyz/wiki/How_to_disable_USB_Attached_Storage_(UAS)
USB Attached Storage (UAS) is now commonly found for USB 3.0 storage devices. However, this sometimes causes issues with non-compliant adapters requiring it to be disabled. Issues with having UAS enabled include slow write performance, or having the device randomly drop off until the USB connection is reset.
Though I've never had the issue myself so don't know whether disabling such feature would help.
Thanks for your help! Gonna test it tomorrow. I wonder if its true, why the hell don't they disable it by default lmao damn
Update: Alright so my HDD which has 2 partitions (1st : NTFS | 2nd: NTFS + Veracrypt) seems to be working flawlessly with the first partition with windows 10 comparable speeds on read and write without any data loss or crash whatsoever without having to disable UAS. I have confirmed that the issues are indeed happening in veracrypt as I reformatted the 2nd partition with LUKS + XFS. Now the partition is working flawlessly. Such would confirm that the issue is not from the NTFS driver (as the 1st partition has no issues) and the issue isnt from my HDD (as the newly formatted second partitions works flawlessly) thus the issue is veracrypt. I hope this will help you troubleshoot.
I have this problem sometimes with a volume mounted from an USB-C external SSD. I suppose USB is not suitable for a connection that must absolutely never be interrupted.
If for you it's all internal drives, there might be something awry in your drivers (as mentioned), or worse, your hardware.
I have this problem sometimes with a volume mounted from an USB-C external SSD. I suppose USB is not suitable for a connection that must absolutely never be interrupted.
If for you it's all internal drives, there might be something awry in your drivers (as mentioned), or worse, your hardware.
Actually its through USB in my case too ty for your comment tho
Ok so I got two partitions on one drive, Main and Secure. Secure is a veracrypt NTFS partition. When I mount it with veracrypt and move data, sometimes what happens is that the Main partition somehow disappears from the File Manager and all folders on Secure are suddenly empty. Now this sometimes results in the data that was supposed to have been written to not be written.
It seems the problem might happen when you try to to delete a file or rename it.
Expected behavior
Move data without loosing it
Observed behavior
Steps to reproduce
Screenshots
Your Environment
Please tell us more about your environment
VeraCrypt version: latest
Operating system and version: latest fedora linux
System type: 64 bit