MacOS Sonora saving not possible file corruption

[bones78]

On MacOS 14.0 the behavior is, that if I open my container and in the container open a file and modify it, it is not possible to store it. After this, the folder is total blank. If I try it on Windows 10 also with the latest version of VeraCrypt (1.26.7) everything is working fine. There I can store/modify everything. On MacOS I have installed MacFuse 4.5.0.

Expected behavior

Work on MacOS without problems

Observed behavior

corrupt files and the whole folder.

Steps to reproduce

1. open VeraCrypt
2. open the .hc file
3. in the folder open e.g. a .docx file and try to safe the changes
4. LibreOffice said: Error saving document xxx General input/output error when accessing /Volumes/xxx
5. If I take a look on the folder all files are gone. If I dismount and remount the .hc file the data are still vanished.

Screenshots

Your Environment

MacOS 14.0, on Intel Core Windows 10 (latest Updates) Please tell us more about your environment

VeraCrypt version: on both systems 1.26.7. Operating system and version: See above System type: 64bit both systems

[memoryxy]

I've encountered this issue as well！！！ Mac OS Sonora，m1 chip

[ebdoran]

Same issue here.

[Mattoje]

Works correctly here:

1. with a newly created hc container (exfat)

2. with one of my "old" hc containers (fat)

macos 14, intel chip, MacFuse 4.5.0, Libreoffice 7.6.1.2

[bones78]

I have created a new container with fat format. Saving a file with Libreoffice Version: 7.6.2.1 works in one test. But it is not stable! If I copie a normal pdf file to the folder I get an error 36. If I copy the same file to another folder there is no problem. The promel occours also with other file types. So it has something to to with VC/MacFuse.

[phlampe]

Same issue here.

Macbook Air M2, updated yesterday to Sonoma (macOS 14) from Ventura (macOS 13), opened my tc file with Veracrypt 1.25.7 or .9 after updating MacFUSE to 4.5.0, got a message when I closed it (but in a hurry, didn't check it), and realized today that my encrypted file appeared empty.

Freaked out...

Updated Veracrypt to 1.26.7, tried again, no change (disk appears empty).

I finally opened it by using an older Mac running an older version of MacOS, transferred all the files (they hadn't disappeared) to an encrypted dmg and felt better...

[idrassi]

Thank you all for reporting this issue and sharing your experiences. I've tried to reproduce the problem on my end using MacOS 14.0 (Sonora) with MacFUSE 4.5.0 and VeraCrypt 1.26.7, but I was unable to observe the issue that you're experiencing.

However, based on your detailed accounts, this issue appears to be similar to an existing issue reported on the MacFUSE GitHub repository: https://github.com/osxfuse/osxfuse/issues/971. That particular issue affects the Dropbox macOS client on Sonora and involves MacFUSE and the Error 36 @bones78 reported. As of now, there is no update or resolution provided on that MacFUSE issue, and VeraCrypt relies on the MacFUSE infrastructure for its operation on macOS. So, in this case, VeraCrypt is somewhat powerless to resolve this underlying instability.

That said, we are actively looking into alternative solutions to improve stability on macOS. One option we are planning to implement is the support for FUSE-T (https://github.com/macos-fuse-t/fuse-t), which doesn't require a kext (Kernel Extension) module. Apple has made it increasingly difficult to use third-party kext modules, and FUSE-T could offer a more stable experience.

[SimonXIX]

A quick note to say I have experienced the same issue with a FAT16 volume. I'm able to read from the volume but attempting to write to any file zeroes the whole file. Moving files over directly results in an Error 36 and an empty file.

• macOS Sonoma 14.1 with Apple M1 chip
• VeraCrypt 1.26.7
• macFUSE 4.5.0

[bfleischer]

@idrassi

Feel free to correct me, in case my assessment is wrong ...

VeryCrypt uses macFUSE to mount a virtual hidden volume containing a .dmg file. This .dmg file is a byte-level view of the decrypted raw container data. The .dmg file is then mounted using standard macOS tools to provide the virtual volume the user interacts with. This means that macFUSE is not even directly involved in file system operations on the virtual, decrypted volume.

Assuming exFAT is used, exFAT handles the save operation which eventually results in the .dmg file on the hidden macFUSE volume being altered. Then those changes are handed to VeryCrypt which updates the encrypted container on disk. This is a rather complicated chain and involves many subsystems.

I assume you investigated the issue thoroughly, before pointing a finger at macFUSE. Could you provide more information about your findings and what makes you believe macFUSE is to blame for the issue. This would actually be very helpful in looking into the issue from the macFUSE end and fixing it, in case macFUSE is to blame.

That particular issue affects the Dropbox macOS client on Sonora and involves MacFUSE and the Error 36 @bones78 reported.

DropBox does not even use macFUSE. The macFUSE issue you are referring to does not contain any useful information.

macFUSE is being used by many third-party file systems, but I never heard of any issue like this before. Of course, this is not conclusive evidence, but it means that there is probably more to it and VeryCrypt most likely plays a role here.

You are saying VeryCrypt is powerless to resolve the underlying instability, but I don't remember you ever opening an issue in the macFUSE bug tracker.

[starless72]

I just switched to a MacBook Pro with M3 Pro running Sonoma 14.2.1, and encountered the exact same issue using VeraCrypt 1.26.7 with MacFUSE 4.5.0, on an old container formatted as FAT which I've been using for years on older VeraCrypt and MacFUSE versions.

I performed some tests moving all files inside a new container formatted as exFAT and for the moment it seems to work fine.

[Nathan187]

@starless72 thanks for your posting. i got tired of the standard response of "it's not us (vera crypt), it's mac fuse", etc etc. the container would disappear when i would copy a lot of files to it. as much as i don't like exFAT, i created a container with that and haven't had any problems.

[SimonXIX]

@starless72 thanks for your posting. i got tired of the standard response of "it's not us (vera crypt), it's mac fuse", etc etc. the container would disappear when i would copy a lot of files to it. as much as i don't like exFAT, i created a container with that and haven't had any problems.

Thanks as well @starless72, I've done the same since there doesn't seem to be any progress on getting this resolved. exFAT not ideal but it'll have to do for now.

[shissam]

I ran into this only today, but I don’t think this is a macFuse problem per se - but something underlying within the msdos fstype for volumes created NOT by Sonoma - perhaps!

I have a “legacy” veracrypt volume - legacy.vc

• header: i have absolutely no recall as to what/how this original verycrypt vol was created, i do recall it was originally created on a Windows box - likely Win7 or Win8 - and I created it (when I moved from truecrypt to veracrypt)
• fstype: msdos
• size 1M
• if there is a way for me to show what the header/structure of this original veracrypt volume is please let me know

Current version numbers:

• macFuse: 4.6.0
• Sonoma: 14.3.1
• arch: Intel
• veracrypt: VeraCrypt 1.24-Update8

Problem exhibited here under “legacy” msdos volume:

- $ BACKUP_VOLUME_PATH="/Volumes/xHD/legacy.vc"

- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /Volumes/tc64

- $ mount | grep msdos
/dev/disk2 on /Volumes/tc64 (msdos, local, nodev, nosuid, noowners, noatime, mounted by shissam)

#
# cat creat’s and write’s - creat works, write fails
#
- $ cat > /Volumes/tc64/myjunk.txt
Hello World 
cat: stdout: Input/output error

#
# dir entry thinks there is 12 bytes - but it is not there
#
- $ ls -l /Volumes/tc64/myjunk.txt
-rwx------  1 shissam  staff  12 Feb 17 10:19 /Volumes/tc64/myjunk.txt

#
# look - empty (no output)
#
- $ cat /Volumes/tc64/myjunk.txt

#
# dirent is now correct
#
- $ ls -l /Volumes/tc64/myjunk.txt
-rwx------  1 shissam  staff  0 Feb 17 10:19 /Volumes/tc64/myjunk.txt

#
# md5sum of nothing just to make sure
#
md5 -r /Volumes/tc64/myjunk2.txt
d41d8cd98f00b204e9800998ecf8427e /Volumes/tc64/myjunk2.txt

#
# dismount
#
- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --dismount /Volumes/tc64

Now (no problem) exhibited here with “new” msdos volume:

- $ BACKUP_VOLUME_PATH="/Volumes/xHD/backup.vc"

#
# took all the defaults EXCEPT pick size 1M and fstype ‘msdos’
#
- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --create "$BACKUP_VOLUME_PATH"
The VeraCrypt volume has been successfully created.

- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /Volumes/tc63

- $ mount|grep msdos
/dev/disk2 on /Volumes/tc63 (msdos, local, nodev, nosuid, noowners, noatime, mounted by shissam)

- $ cat > /Volumes/tc63/myjunk.txt 
Hello World

- $ cat /Volumes/tc63/myjunk.txt 
Hello World

- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --dismount /Volumes/tc63

- $ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /Volumes/tc63

- $ cat /Volumes/tc63/myjunk.txt 
Hello World

- $ ls -ltr /Volumes/tc63/
total 1
-rwx------  1 shissam  staff  12 Feb 17 10:09 myjunk.txt

[starless72]

@shissam thank you for the info. If you continued using it, do you still confirm the "new" MSDOS volume is still working fine? As far as I recall, before using exFAT I tried to create a new FAT volume on Sonoma and I encountered the same issues as in the "legacy" volume.

[shissam]

as of today - what I eventually did was create a whole new msdos 2Mbyte volume (and accepted all the other default options) using Veracrypt CLI on OSX Mojave ( my initial test above was on Sonoma ) and rsync'ed my legacy 1Mbyte volume files (created a long time ago as discussed above) over to the new 2Mbyte volume.

That specific new Veracrypt volume was then pushed to two other OSX's (Monterey and Sonoma) machines. All has been working fine since Feb 18th on all three of those OSX versions.

I hope that answers your questions - I DID NOT try exFAT but I will in the next day or so and report what I saw on Sonoma with exFAT.

[shissam]

@starless72 here is my exFAT experiment - bottom line, it appears to work fine. If there is something else you'd like me to try, let me know.

#
# create exFAT veracrypt vol using linux cli

$ veracrypt --text --version
VeraCrypt 1.24

$ BACKUP_VOLUME_PATH="linux-exFAT.vc"
$ veracrypt --text --create "$BACKUP_VOLUME_PATH" --volume-type normal --size 1M --encryption AES --hash sha512 --filesystem "exFAT" --pim 0 --keyfiles "" --random-source /dev/random
Re-enter password: 

Done: 100.000%  Speed:   58 KB/s  Left: 0 s         

The VeraCrypt volume has been successfully created.
$ veracrypt --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /media/tmp
$ mount|grep vera
veracrypt on /tmp/.veracrypt_aux_mnt1 type fuse.veracrypt (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other)
/dev/mapper/veracrypt1 on /media/tmp type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)
$ df /media/tmp
Filesystem             1K-blocks  Used Available Use% Mounted on
/dev/mapper/veracrypt1       768    84       684  11% /media/tmp
cat > /media/tmp/myjunk.txt
Hello World
$ ls -l /media/tmp/myjunk.txt
-rwx------ 1 1000 1000 12 Feb 26 09:26 /media/tmp/myjunk.txt
$ veracrypt --dismount /media/tmp
$ veracrypt --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /media/tmp
$ cat /media/tmp/myjunk.txt 
Hello World
$ veracrypt --dismount /media/tmp

#
# move this volume to a Sonoma machine

$ scp $BACKUP_VOLUME_PATH sonoma_machine.:~/
Password:
linux-exFAT.vc                  100% 1024KB  14.2MB/s   00:00    

#
# now on Sonoma
$ BACKUP_VOLUME_PATH="linux-exFAT.vc"
$ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /Volumes/tc60
$ mount | grep tc60
/dev/disk3 on /Volumes/tc60 (exfat, local, nodev, nosuid, noowners, noatime, mounted by shissam)
$ cat /Volumes/tc60/myjunk.txt 
Hello World
$ cat > /Volumes/tc60/morejunk.txt
More Hello World
$ cat /Volumes/tc60/morejunk.txt
More Hello World
$ ls -l /Volumes/tc60/
total 16
-rwx------  1 shissam  staff  17 Feb 26 09:33 morejunk.txt
-rwx------  1 shissam  staff  12 Feb 26 09:26 myjunk.txt
$ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --dismount /Volumes/tc60
$ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /Volumes/tc60
Enter password for /Users/shissam/linux-exFAT.vc: 
$ ls -l /Volumes/tc60/
total 16
-rwx------  1 shissam  staff  17 Feb 26 09:33 morejunk.txt
-rwx------  1 shissam  staff  12 Feb 26 09:26 myjunk.txt
$ cat /Volumes/tc60/morejunk.txt 
More Hello World
$ cat /Volumes/tc60/myjunk.txt 
Hello World
$ /Applications/VeraCrypt.app/Contents/MacOS/VeraCrypt  --text --dismount /Volumes/tc60

#
# pull updated volume back to linux
# 
$ scp sonoma_machine.:~/$BACKUP_VOLUME_PATH .
Password:
linux-exFAT.vc                   100% 1024KB  16.8MB/s   00:00 
$ veracrypt --text --mount --pim 0 --keyfiles "" --protect-hidden no "$BACKUP_VOLUME_PATH" /media/tmp
$ ls -l /media/tmp/
total 8
-rwx------ 1 1000 1000 17 Feb 26  2024 morejunk.txt
-rwx------ 1 1000 1000 12 Feb 26 09:26 myjunk.txt
$ cat /media/tmp/morejunk.txt 
More Hello World
$ veracrypt --dismount /media/tmp
$

[starless72]

Thank you @shissam, I'm actually using an exFAT volume since 2 months now and it's always been working fine.

I was more interested in your MSDOS/FAT experiment, because as far as I recall I could not make it work on Sonoma: my old TrueCrypt volume was not working anymore in the new OS with the new VeraCrypt, and I also got read errors when creating a new FAT volume directly using the new VeraCrypt, from scratch.

But maybe something has changed now, after some OS upgrades: I'm now using Sonoma 14.3.1 (vs 14.2.1 in my previous tests), I tried again creating new FAT volumes and they appear to be working fine. Also macFUSE has been upgraded to 4.6.0 now, for the record, even though I tested successfully in 4.5.0.

[shissam]

@starless72 - so 2 days after writing that above, the Mojave-created 2M msdos volume created by Veracrypt on Mojave and moved to Sonoma failed on Sonoma.

The file which had about 11k bytes went to zero on the Sonoma mounted volume and I could not write any "new" bytes to that file (cat > ...) - BUT I could write a new file on Sonoma on that same volume. When I dismounted the now "sick" volume and moved that back to Mojave, I could mount the "sick" volume and I could see the wiped out file (zero bytes) was still there AND I was able to successfully write "new" bytes to that file (which I could not do on Sonoma).

I have set that "sick" volume aside and re-traced my steps above for a new 2M msdos volume, but used Sonoma (14.3.1) and Veracrypt (1.24-Update8) on Sonoma with macFuse (4.6.0) which I have been doing now for 1 week to see what happens.