Hi, when creating or mounting NTFS formatted containers on Linux I need to provide my password. I assume that veracrypt does a sudo in the background. Why is that required? I never require special permissions when attaching NTFS formatted external disks and I can also format them w/o elevated permissions. Requiring root permissions prohibits us to distribute such containers to users which don't have the possibility of elevated permissions on their systems (which is usually the case in centrally managed...
Hello, GUI and Console packages seem identical with the only difference being the GUI missing in the Console package. I.e. it looks as if I can also use veracryptfrom the GUI package in commandline mode in scripts, which would make the GUI package a "superset" of the Console package. Is that so or are there other differences to consider? Basically I would need the GUI package for interactive work but still be able to use veracrypt in commandline mode for automated creation of encrypted containers....
Dear all, I am currently implementing a scripted, non-interactive way to create encrypted VeraCrypt containers on external harddrives on a Linux system. The container should always use all available space on the external drive. Is there a way to detect exactly how much space is available? I can list the available disk space with df -hl, however - probably due to rounding effects - these values are often to high. The maximum available disk space displayed in the VeraCrypt UI is mostly smaller than...
When automating the creation of encrypted containers, the password can either be given as plaintext on the commandline (--password, which is unsafe) or is asked interactively (which is not an option for automated workflows). It would be great, if the password could be read from a previously created file like: pwgen -syn 56 1 > /tmp/secure.pw veracrypt --text --create=/tmp/vol.vc --password-from=/tmp/secure.pw ... Cheers, Frank
Hello, currently on Linux veracrypt --help a) prints a list of options with short descriptions to stdout, and b) opens an graphical window with a differently formatted and more detailed list of commandline parameters c) even more confusing: In a non-graphical environment, the information from the graphical window is printed to stdout and not the information that is printed to the terminal in a graphical environment There are quite a few problems with this behaviour: a) while the window is open, the...
I didn't have the chance to deal with this specific issue any more and I can't currently reproduce it any more. Other problems have popped up instead (I'll post them). I suggest to close this ticket (I would close it myself, but I don't know how)
DavMail working for shared calendars but not for my personal one
I'm not sure on how to proceed here. Can/should I provide more information or do some specific testing? Is the observed *.ics vs. *.EML issue (https://sourceforge.net/p/davmail/support-requests/335/#dd27) relevant? The 403 error message looks like a http server-to-server communication problem. In our environment we place meeting schedules in a shared calendar and having the possibility to have reminder for those events would be quite important.