Veracrypt Containers are not detected as changed

This is a huge issue for me - my veracrypt containers are not being detected as changed even as I change their contents. I suspect this has something to do with the fact that neither the file modification timestamp nor the file size changes as I modify their contents. Not being detected as changed means that it’s not being synced by the client, and won’t be accessible from elsewhere or from other clients.

System info:
Windows 10
Nextcloud Windows client v2.2.4 Build 2

1 Like

A workaround: Use Windows’ ‘copy’ command to update the modified date on the files.

You can do this by making a batch file with
copy /b filename.hc +,,


In TrueCrypt there was an option in the settings where you needed to uncheck:
Preserve modification timestamp of file containers


Huh, didn’t notice that option before. Thanks!

Man I wish I had read this post a little earlier just lost all my changes in my text and excel files from one of my machines.
As Murphys law predicts I deleted the newest version of the container on one of the machines I was working on and can now only restore the old ones from the nextcloud server.

Does anyone know if there is a way to restore the containers if you got rid of them by disabling the sync for that folder in the nextcloud client.
meaning nextcloud deleted it and it’s not in the windows trash bin.
On top of that when I switched the sync back on that stuff probably got overridden by the old containers from the server.

I guess I’m at the point where I have to deep scan to find old versions of the containers and restore those and then try to merge the files.

But damn that just caused me to loose a lot of work.
I can probably get it back but the amount of work to do so…

With some luck you can use data recovery tools. But if it has been overwritten, this will be difficult/impossible. Excel sometimes auto-saves your files. Perhaps you can find or recover such a file on your system.

@FredFS456: Did this really resolve your problem? I used TrueCrypt on DropBox for a long time (1GByte container) and whether this option was set one or the other way, Dropbox always did an indexing operation on theTruecrypt container on dismount (even if nothing had changed inside) and made the container file to synchronize with the cloud copy (and the other local copies on other comps). The actual synch time was short, though, as DropBox is aware of the block cipher structure of a true crypt container and thus can avoid to synch the full container size, if not much or nothing has changed.
I would want to move to a VeraCrypt and NextCloud couple, but I am a) not sure whether VeraCrypt will work nicely in this respect (will make a test with Dropbox soon) and b) I seem to have read not long ago that NextCloud is NOT AWARE of the block cipher structure, thus would synch the full container size in case of even minor changes (anybody up to confirm or otherwise?)

@FredFS456 : Found a thread on ‘delta-synch’ from mid last your (about). Obviously this is not (yet?) implemented in NextCloud, so TrueCrypt (and very likely also VeraCrypt) containers are not really suited for efficient use with NextCloud…
Let us see whther there is enough demand to push this feature up the priority list?

There is the original feature request. Via bountysource, there are already more than 1300$ for this feature:

You can add money, buy an enterprise subscription (which gives you some influence on the priorities), or start implementing it yourself.

VeraCrypt is a fork of TrueCrypt and should not be very different regarding the sync process.

@tflidd Thanks for these hints, I might need to look into this bountysource thingie, not sure it will help too much though, having seen the discussions. For the time being I’ll keep the TrueCrypt stuff on DropBox, where it works like snap and will use my hosted NextCloud for Archive and Multimedia stuff. Luckily the synch clients coexist peacefully on my Win10 machines :slight_smile:

@pwkl999 Well, as you can see, Nextcloud does not yet have delta sync. For me though, I use fairly small size veracrypt containers (<500MB) and I’m often using them at home where Nextcloud can sync over LAN. Therefore, it delta sync doesn’t really matter for me. However, the tips above did solve the original problem of containers not syncing.

Delta sync would be very very nice to have on Nextcloud, but I understand that the devs are very busy, and that they aren’t nearly as big of a company as Dropbox yet.

Thanks for all the detailed information guys. The discussion made me realize that I overestimated the privacy promise of nextcloud. Shame on me.

Meaning if you host it on one the provider that are recommended on the nextcloud homepage like ocloud they can access whatever they want since they have root access and if one of your sync folders is on a shared windows computer those administrators can also access everything directly even if they don’t even know about the next cloud server.

it’s even worse then that all your data is stored unencrypted on the machine you are using with the sync client by default.

I felt quite stupid talking about encryption or privacy in that context when any admin on a Windows machine can access the files. No decryption needed.

Holy smokes that’s a big whole in the privacy I thought and put the whole stuff in veracrypt containers (since truecrypt is…well you know) since I still loved nextcloud.

Imagine the cold sweat on my head when I realised I lost month worth of document changes since the standard settings didn’t work for synching veracrypt containers.

Since the sync folders get overwritten again and again there was little hope to identify the changes I needed back.

After going back and changing veracrypt settings so that nextcloud would not ignore my work I realised that now nextcloud was always uploading the full container size. Oh come on. Why oh why is there no delta sync if you have to use containers. But hey its opensource I got to figure this out it’s good for all of us.

OK so now I went back and analysed my tree structure to cut the containers into reasonable size containers.
But to be honest that’s not a scenario I would like to explain to anybody not interested in encryption etc.

Loading the dozens of different containers and punching in the secure passwords really is tedious.
You need one big container with delta sync.

So in my opinion nextcloud needs to generate a encrypted container that only the user has the password to.

I’m a little disappointed with nextcloud in the current state.
Instead of trusting Dropbox and admins you have to trust whatever nextcloud provider you choose plus admins.

It opens you up to data loss with undetected container changes and data theft with the provider and the admins on your client.

Most people that I know can’t do their own server and are using shared windows computers.

Which means they are back at square one where they have to trust their administration to not take a peek at their data.

My suggestion would be to generate a container for the data and enable delta sync.

I might also be wrong about everything since I know I can never know it all. So feel free to pick this apart if you got the technical skills to prove me wrong.

All this encryption stuff is a bit complicated and most people don’t pay much attention to it - they are just happy that it is somehow encrypted. And if you want to protect all your data properly, it’s often complicated.