Copying snapshots to XXX was disabled by the preference

I am getting the error “Copying snapshots to XXX was disabled by the preference” when trying to copy snapshots from one storage to the other.

What does that mean and how can I overwrite that?

You have "no_backup": true in the .duplicacy/preferences file which disables backup and copy.

1 Like

Thanks. And when and why is that set? It seemed to appear after doing a check or backup, but I didn’t verify in detail.

How did you run the copy command?

I ran

C:\ProgramData.duplicacy-web\bin\duplicacy_win_x64_2.6.1.exe copy -threads 3 -from storage1 -to storage2

Which completed w/o error. After that I ran a check, which showed missing chunks. I then tried to run the copy command again and got the error that copying is disabled.

The preferences file is updated every time a job is run by the web GUI. Can you just run a copy job in the web GUI (by creating a schedule, adding the copy job, and then clicking the start button)?

I too have had this issue, and the problem happens for copy jobs run from the GUI.

My copy jobs are intermittently failing with this message (some days it runs, and some it fails with the “was disabled by the preference” message. Can you clarify what jobs in the GUI change this preference so I can work around the problem? I am guessing it might be something to do with a “check” job that runs at the same time as the copy job, but it would be good to clarify to understand that better.

Obviously it is probably not ideal to run a check at the same time as a copy for other reasons so i will probably change that anyway.

Copy, check, and prune jobs use the same repository location at ~.duplicacy-web/repositories/localhost/all so they will all write to the same .duplicacy/preferences. A check job sets no_backup to true while a copy job sets it to false. So if a copy job runs at the same time as a check job at exactly the same time then a conflict may occur. The workaround is to disable the parallel checkbox so they won’t run in parallel.

I’d like to reopen this question as I can reproduce it, and am confused about how it is supposed to work. So here is what I have done to trigger it:

  • I have storage #1 and #2, say Gsrc and Gdst
  • I run CLI command from the web version that copies from Gsrc to Gdst
  • I run above in a loop as copy command fails periodically and needs to be restarted due to unrelated bug
  • So basically I run CLI copy command non-stop in sequence, this worked fine in the evening
  • There are two scheduled commands in web that run check on Gsrc and Gdst respectively overnight
  • Scheduled checks have parallel checkmark set to ON as I assumed this will allow to run these in parallel with other operations
  • When I looked in the morning, both checks completed successfully, but my CLI copies were unable to proceed with “Copying snapshots to Gdst was disabled by preference”.
  • Looking at the preferences file indeed shows that storages are blocked with no_backup flag set to true, even though the checks have long since finished
  • If I start and stop copy command from the GUI, then it works and I can get back to running CLI as flags are back to normal.

This does not sound like expected behavior to me. A few questions:

  • Are there any issues running check commands in parallel with anything else? I assume these would be read-only, so at worst checks would report slightly inconsistent results if something else is writing to the storage, which is fine by me.
  • What does parallel checkmark actually does? I assumed it allows to run in parallel, which means exactly NOT to change storage flags to blocking, which it seems it does
  • Whatever is the semantics, it seems that these flags stuck at blocking is wrong regardless if the operations have long since completed.

Right, it is obvious now that setting this no_backup flag is unnecessary. Probably a result of overthinking. I’ll remove it in the next release.

If you really want to get around this problem, just initialize a dummy repository under any directory (by running the init command) and then run copy from there.