Since upgrading to 2.0.3.3_beta receive the following error when backing up to local NFS mount:
Backend quota has been exceeded: Using 179.19 GB of 0 bytes (0 bytes available)
Setting quota-size and quota-warning-threshold do not seem to have an effect.
Other backups to local USB drives do not produce the same error and the backups seem to finish sucessfully.
Hi @tjpepitone, welcome to the forum!
I believe the --quota-size and --quaota-warning-threshold are applied only if the destination itself doesn’t report a quota (though I might be mis-remembering that).
Is it possible the target of your NFS mount has an OS level quota that you might be running into? I suppose it would easy to test simply by trying to manually copy a file to the same folder as the Duplicati destination. If it works then it’s not an OS quota issue and we’ll have to dig into why Duplicati is returning that message. Oh - be sure to delete the file after the test or Duplicati will complain about seeing “extra” files. 
Would it be possible for you to use the job menu “Export” -> “As Command-line” feature and copy/paste your job settings here (with person stuff like email & passwords removed, of course)?
Another useful test might be to see what the quota command says. You might need to install the package first.
Quota is sometimes configurable per user (or group), so be careful if Duplicati Server runs as a different user.
I think you will also see quota information from Duplicati.CommandLine.BackendTester.exe although you might have to find it in /usr/lib/duplicati and have mono run it (i.e. I didn’t spot a user-friendly /usr/bin wrapper script).
Thanks for responding. The backend is an Ubuntu box with the NFS export living on lvm volumes. Should be plenty of space and the backup does finish sucessfully short of the error.
I do use automount for this volume however with the mount point does have the immutable flag set to prevent filling up the local root volume if automount were to fail.
mono /usr/lib/duplicati/Duplicati.CommandLine.exe backup file:///media/NAS/backup/2CR_Local/ /vssd/ /home/tim --accept-any-ssl-certificate=true --backup-name=Local_NAS --dbpath=/home/tim/.config/Duplicati/PBIQGUMACK.sqlite --encryption-module= --compression-module=zip --dblock-size=50mb --keep-time=3M --no-encryption=true --quota-warning-threshold=0 --disable-module=console-password-input --exclude="%HOME%/Desktop/" --exclude="%HOME%/Downloads/" –
What’s the reason for the --quota-warning-threshold=0 setting?
I’m wondering if there may be an edge case bug where a setting of 0% confuses Duplicati. Can you try with it removed or with a non-zero value? (Note that I did test a zero setting in 2.0.3.9 canary and it did not cause the error you’re seeing.)
--quota-warning-threshold
Sets a threshold for when to warn about the backend quota being nearly exceeded. It is given as a percentage, and a warning is generated if the amount of available quota is less that this percentage of the total backup size. If the backend does not report the quota information, this value will be ignored
Default value: “10”
The result is the same with the option removed or with a non-zero value.
Any results from the quota command or BackendTester mentioned earlier. Does anything else perceive quota, for any user, or in any way? As far as I can tell, Duplicati is just querying the .NET API (or Mono’s in this case).
If you are not directly administering the backend box, possibly asking the administrator about quotas may help.
When looking for quotas (and actually for testing Duplicati’s perception of them), can you try a manual mount, thereby preventing automount from changing options, and keeping the environments as similar as possible…
What previous Duplicati worked differently? If it was close enough to 2.0.3.3 beta, changes could be checked.