I’m pretty close to lost. Might need to gather some logs on how this breaks. Meanwhile I misinterpreted this:
(sorry for thinking out loud – you don’t need all the details, but perhaps they will help somebody somehow)
“No filelists found on the remote destination” made me think of the no-files-seen issue, but you proved that files were seen by list. Looking up the message text (thanks for providing it), this was actually from code attempting to recreate the database from backend files, but found it had no dlist (list of files) to start from. Because the dlist contains backup details, it can’t be finalized for uploading until the very end of the backup.
The 3 usual get operations are sampled from remote files known to the database, but no DB may mean no samples. The question becomes – where did the database go? Unfortunately, I don’t do Docker, but think it sometimes becomes an issue of where to keep persistent data. Keeping it outside the container solves the problem of losing it all when you replace the container with a new version, but it needs some special steps.
Duplicati on Synology via Docker?! is a writeup by the person who you worked with on your previous issue.
Docker container sqlite location is an older discussion.
Can’t repair database on synology was one where a 512 MB Synology couldn’t do Recreate due to lack of memory. That initial crash was due to lack of temporary file space. tempdir and other settings control that.
Because you’re on a small system (what memory size?) that can run a small backup but not a larger one, possibly there is some sort of resource issue that arises. I don’t know how it leads to the original message whose source is not known, but appears to be the result of previous problems (which a log might capture).
Duplicati uses temporary file space (I guess from your error yours is at /tmp – is that inside the container?) heavily for accumulating information and staging files for upload to destination. Can you watch free space?
Can you check the job Database tab to see its path, then figure out where that really is? Watch free space. You can also watch the database itself. Especially from a clean start, I’d expect it to start small then grow.
I’m not sure why it’s in the recreate code. I think in some cases it does a repair before backup if it feels the need (and this probably can be seen in the log), however (per repair link), a recreate is due to no database. Specific issue of no filelist is probably because it never got far enough in initial backup to upload the dlist.
A log file was suggested earlier to try to see what got the 504 from NextCloud. That log level was at retry, which is good because it doesn’t show private info like paths, however there are higher levels if necessary.
You can possibly gather some information on any stuck-here situation like the “No filelists found” (is there a file with dlist in its name in the backup destination area) this way, or I suppose you could just try to restart by deleting the database (Delete button) and the corresponding NextCloud files using some manual delete.
I’d be happy if @drwtsn32 has any thoughts on setting up Docker on Synology, and how to check issues.