ulip

@idrassi and all other with the same expiriences. I checked all the requested files and took three screenshots of the security properties of VeraCrypt.exe at the following locations: C:\Program Files\VeraCrypt\VeraCrypt.exe C:\Windows\System32\VeraCrypt.exe C:\Windows\System32\drivers\VeraCrypt.exe I also checked the other requested files, veracrypt.inf, veracrypt.sys and veracrypt.cat in C:\Program Files\VeraCrypt, as well as the corresponding files in C:\Windows\System32\drivers. All files I checked...

Hello, I upgraded VeraCrypt from 1.26.29 to 1.26.30 on two Windows 11 machines. Both machines are used for file containers only. System encryption has never been active on them, and I have no VeraCrypt Rescue Disk. During the upgrade, both attached error dialogs appeared: “VeraCrypt could not confirm that a trustworthy, complete original system loader backup is available in protected storage…” “VeraCrypt cannot safely use the original system loader backup because its ownership, permissions, or file...

Cheers to the perseverance that the community and developers have shown against Microsoft! And thank you for the fact that every now and then there are still people with insight into the processes!

@idrassi: thanks a lot for that information. It works like a charme. Using --use-dummy-sudo-password is not neccessary no more.

Addition: using --use-dummy-sudo-password I have the old behaviour before 1.26.20. Is this intentional at least for Mint Version 22.1 ?

@idrassi: There is a change in the login behavior of version 1.26.20 under Linux compared to older versions: As before, the password for unlocking the container must be entered first, but then - and this is new - the user's login password for mounting the container must be entered, too. It took me a while to realize this. Perhaps the change should be described in a prominent place in the documentation. Am I the only one experiencing this change in behavior? Please let me know if anyone else is experiencing...

@idrassi: There is a change in the login behavior of version 1.26.20 compared to older versions: As before, the password for unlocking the container must be entered first, but then - and this is new - the user's login password for mounting the container must be entered, too. It took me a while to realize this. Perhaps the change should be described in a prominent place in the documentation. Geetings System: Kernel: 6.8.0-52-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0 clocksource: tsc Desktop:...