The wrong quota is used in the disk free check when:
* the share's root volume has quotas applicable to the user,
* the share contains sub-mounted volume(s) (from separate devices, with or without quota),
* the user is copying/moving data to the sub-mounted volume,
* the total size of the copy/move operation is larger than the user's remaining quota on the share's root volume.
This affects any interface that does a pre-copy/move destination free space check (e.g. Windows Explorer, Mac Finder, possibly others) and the connection is using SMB2+ protocols. SMB1 connections do not have the problem, nor does any interface that does not do a pre-copy/move destination free space check (e.g. command line utilities like copy, move, xcopy, robocopy, cp, mv, etc).
I appears the disk free check is being done at the root of the share because the client is unaware the destination path crosses a sub-mounted volume. If the client is sent an IO_REPARSE_TAG_MOUNT_POINT tag when it crosses into the sub-mounted volume, then the client does a free space check properly for the sub-mount's path, and the correct free space information is returned.
A fix was submitted to samba-technical on September 19, 2017 (see "[PATCH] smbd: Added support for IO_REPARSE_TAG_MOUNT_POINT")
Found out yesterday, the fix does not work with Mac Finder.