This reverting in-place is likely not a "supported" method, but it has worked fine for me so far this evening. YMMV
From a console on your NAS, you can manually download and install the old .deb file:
LLAP
This reverting in-place is likely not a "supported" method, but it has worked fine for me so far this evening. YMMV
From a console on your NAS, you can manually download and install the old .deb file:
LLAP
I am having the same problem.. glad I am not the only one.
I believe this is a bug related to a recent change in this pull request #802:
https://github.com/openmediava…7c9cc188be11fa748ff480eed
The error is occurring when the following command is executed against my XFS filesystem. On EXT4 disks, its return code is 0, but on the XFS disk its return code is 2, which OMV is treating as an error. For some reason, the return value of this command is different depending on the filesystem type that is queried.
It seems like there is a XFS blacklist check missing on the quotaoff command?
UPDATE: I installed the openmediavault package version 5.5.9 and this bug went away! This is definitely a new bug related to the recent bug fixes made to the quota management.