If Duplicati is running as root, then please try the described manual test request as root user. User access isn’t directly relevant, whether or not it’s full access. With NFS, root is especially a red flag because it may (unlike the local case) enjoy less access than most users unless ReadyNAS was configured away from its seeming default of squash root access. I think the manual shows a checkbox for that. Is it checked or not?
Having said that, it seems unlikely (although possible) for permissions to allow writing files but not deleting. When checking permissions, I believe it’s the folder permission that matters, not the permission on the file.
Duplicati can go a long time between deletes (but not without writes) which might explain previous success. There are even people who, for security reasons, want Duplicati to do no deletes, and it appears possible.
For the repair failure, was the access error on delete again? Are there files from repair date in the folder? What’s puzzling is whether it’s just deletes that are failing here, or writes too, and for what users and use?
I suppose it’s possible that there’s some odd Mono bug. unRAID is Slackware based, but I’m not sure that Slackware makes Mono available (although there are other sources, and I don’t know what unRAID does).
I’m not quite sure why Duplicati is trying to delete a file so early. Possibly it’s some leftover unfinished work. You can watch the server’s doings live in a different window, under About -> Show log -> Live (pick a level). Information might be a good one. Profiling can write too much. There are also log-file and log-level options.