Rockstor Rock-on Stuck on ‘Installing’: How to Reset a Manually Removed Docker Container

Why Rockstor Gets Stuck on “Installing” After a Manual Docker Removal

When you stop and delete a Docker container directly — rather than through the Rockstor web interface — the NAS software has no way to know you did it. Rockstor maintains its own internal database that records the state of every rock-on: installing, installed, started, stopped, and so on. Manually removing the container leaves a row in that database permanently set to installing, which blocks any further action on that slot and can prevent other rock-ons from being queued.

A reboot doesn’t fix it. The rock-on manager reads the stored state on startup and picks up exactly where it left off.

Step 1: Confirm the Container Is Actually Gone

Before touching the database, verify Docker’s side is clean:

docker ps -a

If you see the qBittorrent container still listed (even as Exited), remove it:

docker rm -f <container_name_or_id>

Also remove any associated volumes if you want a truly fresh install:

docker volume ls
docker volume rm <volume_name>

Networks created by Rockstor for the rock-on can be listed with docker network ls and removed with docker network rm if needed.

Step 2: Reset the Rock-on State in Rockstor’s Database

Rockstor 4.x runs on openSUSE and uses a PostgreSQL database managed through Django. The cleanest way to reset a stuck state is via the Django management shell.

SSH into your Rockstor box, then:

cd /opt/rockstor
source .venv/bin/activate
python manage.py shell

Inside the Python shell, find the stuck rock-on and reset its state:

from storageadmin.models import RockOn

# List all rock-ons and their current states
for r in RockOn.objects.all():
    print(r.name, r.state)

# Reset the stuck one
ro = RockOn.objects.get(name='qBittorrent')
ro.state = 'available'
ro.save()
exit()

The exact name string needs to match what Rockstor has stored — the for loop above lets you see all names and states at once so you’re not guessing.

Valid target states vary slightly by version, but available is typically what an uninstalled, ready-to-install rock-on looks like. If you see a different idle state in the loop output for a rock-on you know is working normally, use that one instead.

Step 3: Restart the Rockstor Services

After updating the database, restart the relevant services so the web UI picks up the new state:

systemctl restart rockstor

On some builds you may also need:

systemctl restart rockstor-pre

Reload the web interface in a fresh browser tab. The rock-on should now show as available to install, and the install queue for other rock-ons should be unblocked.

If the Django Shell Approach Doesn’t Work

A few things to check if the state won’t stick or the UI still shows the wrong status:

• Make sure you saved the object before exiting — ro.save() must run without errors.
• Check for leftover Docker networks or volumes that might confuse the installer on the next attempt.
• Clear your browser cache. Rockstor’s frontend caches some state, and a hard refresh (Ctrl+Shift+R) can reveal the real current state.
• Check Rockstor’s logs at /opt/rockstor/var/log/rockstor.log for any errors that fire when you try to install again.

Why This Happens and How to Avoid It

Rockstor is designed to be the single source of truth for its containers. Going around the UI — even with good intentions, like killing a frozen install — breaks that assumption. The safest approach when an install hangs is to wait for a timeout if possible, or use the Rockstor UI’s own stop/delete controls rather than raw Docker commands.

That said, frozen installs do happen, and the steps above get you back to a clean slate without a full Rockstor reinstall.