@ts678 Thanks for your efforts. Much appreciated!
You said in the other bug:
and above
So if I put those two together and elaborate the error message, I get:
“Found in the DB table, blockset entries with non-zero length, meaning there should be blocks in the backup store for these, and and they should be listed in the table of blocks (table of BlocksetEntry items?), but they’re not there.”
Did I do that right?
If so, then my guess was in the wrong direction. Going from “more files” to “less files” (by going from prived to unprived) should have resulted in something more like actual block entries for which there was no summary blockset entry, not the other way around.
Also, understanding more, I don’t see how any change in the source files selected could result in this kind of a database inconsistency, because aren’t we in a phase of database verification before Duplicati even scans the source set? Unless somehow the selected source files somehow affect indexing into these tables? I doubt that.
Deleting versions is promising. But it’s not going to happen on its own because this error is early before actual backup begins. Till I fix this, no more backups (and thus no deletions) will happen. (Altho, I have set to infinite versions anyway 
Here’s another theory: while running with privs, Duplicate wrote some internal files that got protected, and when subsequently running with no privs, could not read those same files. Could that affect what BlocksetEntries are available? It sound like it’s all in one .db file so I doubt it. Can individual SQL entries be protected, needing privs to access?
Other notes. Yes my backup was big(ish): 20GB. And hundreds of (mostly useless temp) files change each backup (daily).
I think finding the filenames via the SQL query will be very helpful. I will try when I have access to that machine again.