Setting User or Group Quotas

Quotas can be set on a user or group at the filesystem or object store level, as well as the project level. These enforce physical data usage based on the POSIX or Windows identity of the owner or group of the file or directory. There are some significant differences between user and group quotas, filesystem, object store and project data quotas:

User and group quotas can be applied to filesystems, object stores and projects.
Default quotas can be set at the project level and inherited by the project's filesystems or object stores.
Default quotas set at the project level can be changed at the filesystem or object store level.
Default quotas can be retrieved or modified over the SMB protocol.
User and group quotas are implemented using delayed enforcement. This means that users will be able to exceed their quota for a short period of time before data is written to disk. After the data has been pushed to disk, the user will receive an error on new writes, just as with the filesystem or object store-level quota case.
User and group quotas are always enforced against referenced data. This means that snapshots do not affect any quotas, and a clone of a snapshot will consume the same amount of effective quota, even though the underlying blocks are shared.
User and group reservations are not supported.
User and group quotas, unlike data quotas, are stored with the regular filesystem or object store data. This means that if the filesystem or object store is out of space, you will not be able to make changes to user and group quotas. You must first make additional space available before modifying user and group quotas.
User and group quotas are sent as part of any remote replication. It is up to the administrator to ensure that the name service environments are identical on the source and destination.
An NDMP backup-and-restore operation of an entire share will include any user or group quotas. Restores into an existing share will not affect any current quotas.