This is, I’m afraid, @phillxnet’s expertise so I’m unsure of the root cause of the issue here. In the meantime, you should be able to workaround this by disabling quotas (they are currently not enforced).
@aremiaskfa I found that for resizing currently the quotas need to be turned on. I usually have them turned off. When I wanted to perform a resizing some time ago (on 4.1.0-0), I needed to turn quotas back on for the pool where I wanted to perform a resizing of a share.
For some reason, in my case the change in the WebUI didn’t hold, so I had to do it at the command line…
btrfs quota enable /mnt2/<volume_name>
and then after resizing or creating a new share, I disabled them.
I just tried it on my 4.6.9-1 installation … and this time it didn’t complain about it, so not sure whether I did anything different or something has changed, but I am also running on the Linux: 6.3.1 now (backport for Leap 15.4) so a new version of btrfs-progs might have taken care of that problem …
I guess, if currently have quotas on, then @Flox 's recommendation is the one to follow, and if you currently have them off, then you can see whether following mine addresses it. But as mentioned above, since we’re not enforcing quotas the resizing would be only for visual/cosmetic purposes at this moment.
to further add to this, I am referencing another forum posting for which we addressed new share generation (I completely forgot that I had posted that originally)
and that scenario was fixed in Release Candidate 4.5.8-0
Houston, we’ve had a problem.
Error running a command. cmd = /usr/sbin/btrfs qgroup assign 0/256 2015/7 /mnt2/KOR-03. rc = 1. stdout = [‘’]. stderr = [‘ERROR: unable to assign quota group: File exists’, ‘’]
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/rest_framework_custom/generic_view.py”, line 41, in _handle_exception
yield
File “/opt/rockstor/src/rockstor/storageadmin/views/share.py”, line 279, in put
share_pqgroup_assign(share.pqgroup, share)
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 1563, in share_pqgroup_assign
return qgroup_assign(share.qgroup, pqgroup, share.pool.mnt_pt)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 1632, in qgroup_assign
raise e
File “/opt/rockstor/src/rockstor/fs/btrfs.py”, line 1580, in qgroup_assign
run_command([BTRFS, “qgroup”, “assign”, qid, pqid, mnt_pt], log=False)
File “/opt/rockstor/src/rockstor/system/osi.py”, line 289, in run_command
raise CommandException(cmd, out, err, rc)
system.exceptions.CommandException: Error running a command. cmd = /usr/sbin/btrfs qgroup assign 0/256 2015/7 /mnt2/KOR-03. rc = 1. stdout = [‘’]. stderr = [‘ERROR: unable to assign quota group: File exists’, ‘’]
#################################################
A work around is to go to: Storage>Pools and disable the “Quotas” of the specific pool in which your “Share” falls under.
After the “quotas” has been disabled return to Storage>Shares select your share then Resize.
Then back to Storage>Pools and re-enable the specific pool of your share.
The above worked for me.
*resize issue
*resize issue 00
*resize issue 01
This 'ERROR: unable to assign quota group: File exists', is very likely the same, now fixed issue reported again recently by forum member @Stevek in the following forum thread:
Our latest 5.0.13-0 testing release (in Release Candidate phase), has the fix:
The caveat here, and why it has taken a while to identify at least one cause of this issue, is that it pertains to imported Pool. Not newly created pools, or pools that have had quotas disabled and then re-enabled - hence the nicely reported work around here by @MyOwn.
Details of the fix, which relate to our still developing support for btrfs quotas are available in the following GitHub pull request where there are examples of what happens on imported pools where quotas were, and remain, active; that can lead to this now fixed bug:
There is also an example of the same reproducer Pool being reset to no longer provoke this bug due to a quote disable/re-enable cycle.
