Rockons wont start

Jorma_Tuomainen · July 4, 2025, 2:37pm

Hi,

I did the stupid thing of cleaning old snapshots and btrfs had some troubles with it. I seem to have my data around and only couple of errors (and balance doesn’t seem to start…)…

but anyway, get this error even when starting docker manually:
docker: Error response from daemon: stat /mnt2/rockons/btrfs/subvolumes/e0ef0dea9825c430a4c78c343a061b7cddf73535a2b6de0a1561c5446617c829: no such file or directory.

If I create directory there, it’s another error. Is there anyway to clean it all and start again (it’s just containers anyway, data is elsewhere)?

Hooverdan · July 5, 2025, 7:22pm

Sorry for the short response.
If you can uninstall all your Rockons (worst case use the command line).
You can create a new Rockon root and associate it in the service settings with the Rockon service. Then delete the old one. And then reinstall your Rockons. You can probably find after the first install which of the sub volumes/snapshots while the container layers and avoid deleting them in the future

Jorma_Tuomainen · July 6, 2025, 7:32am

Yeah, didn’t understand how the snapshots were related to the rockons. The whole pool has problems now (another HDD bought the farm), rebuilding space cache right now and removing missing drive. Will recreate if I get this up (I do have backup NAS though).

phillxnet · July 7, 2025, 8:39am

@Jorma_Tuomainen Hello again.

Firstly, what @Hooverdan said re recreating the Rock-on-root on a new share. And I’ve found a reboot useful sometimes to fully reset docker.

And, regarding no Web-UI guard rails plus:

We have the following issue that has some useful explanations & upstream links:

github.com/rockstor/rockstor-core

rock-ons-root snapshot warning

opened 10:19AM - 28 Mar 17 UTC

phillxnet

Thanks to knucklehead101, mrseth1, glenngould, MvL, and D_Jones in the following… forum threads for highlighting this issue. Since docker (Rockons) use snapshots to manage image layers their deletion will break installed Rock-ons. Provide a banner / warning against this action in the current Rock-ons-root share (sub-volume). It is proposed (by the issue author) that this banner / warning / explanation be placed inside the "Snapshots" tab on the currently active rock-ons-root share (sub-vol). Referenced forum threads: https://forum.rockstor.com/t/rock-ons-snapshot-removal/637 https://forum.rockstor.com/t/deleting-snapshots-breaks-rock-ons/2431 https://forum.rockstor.com/t/what-is-the-logic-of-rockstor-if-there-are-no-scheduled-snapshots/2928 https://forum.rockstor.com/t/solved-headphones-rock-on/3034 https://forum.rockstor.com/t/broken-rockons-after-update-or-snapshot-removal/3039 Possible background docker reference: https://docs.docker.com/engine/userguide/storagedriver/btrfs-driver/ Note additional 'auto clean' functions can later be added to this share (sub-volume) using the recently introduced ' docker system prune' and friends but that is for another / later issue. This issue is about user communication re docker snapshot use and visibility within the UI. We have an open partner issue in our rockstor-doc repo: **explain rock-ons-root snapshots** https://github.com/rockstor/rockstor-doc/issues/166

I.e. from: BTRFS storage driver | Docker Docs we have:

Only the base layer of an image is stored as a true subvolume. All the other layers are stored as snapshots, which only contain the differences introduced in that layer.

We are really just missing a warning here. We already indicate if a snapshot belongs to the Rock-ons-root share - but provide no guard against its deletion.

Hope that helps.

Jorma_Tuomainen · July 10, 2025, 11:59am

Yeah got it working (emptied the rockons root). It was the second disk (after raid1 balance) that died that caused the problems. Still it seems that the btrfs mode comparing to overlay is redundant (since you can snapshot the whole rockons volume anyway).