@mluetz A belated welcome to the Rockstor community.
rockstor:master ← phillxnet:1867_shares_unmounted_after_reboot_-_3.9.2-3
opened 06:12PM - 08 Dec 17 UTC
We already log the state of quota not enabled via run_command log=True on the li… ne relating to this pr and given a failure / exception here (pre pr) breaks mounts we should simply log and move on. Our parent function already deals with this scenario by returning vol / pvol sizes of 0.
This is akin to the treatment we give to command lines involved in the following functions withing the same file: is_subvol, subvol_info, add_share, balance_status, device_scan.
Although this pr does address a failure to mount shares due to 'quota not enabled' it does not address the reason for the quota not being enabled in the first place. This however can be addressed in a future pr, along with it's various ramifications ie 0 usage against shares and an inability to change share sizes etc.
Fixes #1867
Proof of fix re shares unmounted was accomplished by re-producing the issue (fresh 3.9.2-3 install setup with an example plex config as per:
http://rockstor.com/docs/docker-based-rock-ons/plex-media-server.html#plex-server-rock-on
Then rebooting.
There after every reboot failed with exceptions as noted in the issue text (quota not enabled).
Post pr every reboot thus far successfully remounted all shares and started the plex rock-on but with the above noted caveats re shares.
@schakrava Ready for review.
then reboot and then enable quotas on your pool via:
btrfs quota enable /mnt2/Cloud
This work around or it’s kin should be released soon if you are not happy with making the edit as per the pending review pull request commit.
out, err, rc = run_command(cmd, log=True)
to
out, err, rc = run_command(cmd, log=True, throw=False)
ie we add a “, throw=False” to the end of the bracketed contents.
Note that this is not as yet a reviewed pull request and I’m pretty sure I’ve missed something but as an emergency fix if that is what is required it worked for me here. Though editing code is not advisable if you are unfamiliar with it.
An alternative is to apply the patch via the following wiki entry:
In some instances there may be the requirement to test a patch; this is most likely to be associated with small changes that need testing on hardware that is not in the hands of a core developer. It is advised that if you undertake this task that you are prepared to break your current install. It is also advisable to be running the latest testing channel updates; however this may not be required in some circumstances and the author of the patch should be able to advise accordingly.
The followin…
using the following url:https://github.com/rockstor/rockstor-core/commit/c9eecdd9476a795baa6b5fd07287addfeacf4591.patch
Please do read that wiki if you are to attempt the patch method, but essentially you (as root) do:
yum install patch
# answer y
cd
curl https://github.com/rockstor/rockstor-core/commit/c9eecdd9476a795baa6b5fd07287addfeacf4591.patch > pending_1867.patch
patch -d /opt/rockstor/ -p1 < pending_1867.patch
And you should have the change made for you.
Then do the reboot and quota enable bit.
That should at least get your shares back up, else we await the ‘proper’ resolution.
Hope that helps and thanks for your report.
EDIT: As from version 3.9.2-5 the above referenced patch is already applied / included.