There is some code in place to manage this:

Maybe this code is bugged for your situation, or you use symlinks like the todo suggests? I don't have a linux setup to test this.

I don't have a linux setup to test this.

Unfortunate. I only have old VMs. Maybe @durcom2 can test whether this old theory about what's a drive can explain the issue:

Backend quota has been exceeded after apparently successful backup

I have no resources to test code changes. This is a definite issue/bug though that developers need to look at.

I have no resources to test code changes. This is a definite issue/bug though that developers need to look at.

For anyone to look at this, you should probably give a bit more information about your specific setup, so that others can reproduce the issue:

• what kind of drives / mounts are you using and are there other mounts in your system that might confuse this function?
• does this happen with all mounted drives or only specific ones?

Assuming that GetDrives() returns your mountpoint as a drive, it should make a correct free space calculation. So there must be something wrong with that function on your system. In that case, it is not a Duplicati issue but rather a mono issue.

In the linked forum thread above there are more troubleshooting steps that might give more insight. Without more info probably nobody can fix this.

nothing special about my setup...minimal ubuntu 22 install
only "unusual" thing is the mountpoint where the duplicati files are stored is on a zfs volume
The warning on the disk quota mentioned above lists Exactly the space used and free space available for the root volume (/) (a standard ext4 linux volume) so it is returning the space for the root volume and not the zfs volume. It does not appear that duplicati can handle a zfs mountpoint properly.

I have no resources to test code changes.

That wasn't the request. It was to see how the mono GetDrives example program works on your system if you can compile it.

Assuming that GetDrives() returns your mountpoint as a drive

is the question that we can't answer on your system. We probably can't get mono changed, but possibly we can work around it.

I have no resources

If you installed the mono-devel package per the manual, you should have gotten mono-mcs with man mcs and /usr/bin/mcs.
DriveInfo.GetDrives Method at learn.microsoft.com has an example with a Copy button. Put it in a file and run it, for example:

mcs -out:GetDrives.exe GetDrives.cs
mono GetDrives.exe

If your drive isn't listed, by mono, there's your problem. Duplicati doesn't look at or know your filesystem type, but mono does.

If you're totally uncomfortable with running Microsoft example code, then could you grep /etc/mtab for ZFS filesystem to post?
Testing with a loop versus tmpfs mount (I don't have ZFS on this VM) make me think a line starting with a device will get in, e.g.

/dev/loop3 /mnt/loop ext2 rw,relatime 0 0

but a line that doesn't start like that takes its chances on the mono lib linked from above link providing special code to get it in. Here is a direct link, and reading it lines up well with test results. Also adding credibility is that .NET 6 doesn't show the problem.
That's no help until Duplicati can migrate to .NET. Sadly, DriveInfo(String) Constructor has the same issue (maybe same cause).

I'm not sure what other ways one can get quota information. Maybe someone more familiar with .NET can think of something...
If there's none, then maybe a workaround would be to provide an option to just turn off quota check until the value is available.

So asking again for information from system.

This issue has been mentioned on Duplicati. There might be relevant details there:

https://forum.duplicati.com/t/backend-quota-exceeded-i-know-its-been-covered-but/16488/16

This issue is stale because it has been open for 15 days with no activity.

This issue was closed because it has been inactive for 15 days since being marked as stale.