New intall worked great until update

Leap iso, home build nas. Everything worked until updating and now both rockstor.service and rockstor-pre do not start. rockstore-pre failed with status “exit-code”. when I looked in journalctl. I do see that there is no module names ‘scrips’ mentioned within. Where may one get scrips and how did it get missed?

Hi @darylk ,

Can you let us know which version of Rockstor you updated to? If you’re not sure, you can verify with zypper info rockstor.

Similarly, would you be able to confirm what ISO you used to install Rockstor?

This sounds like something went wrong during your update, so let’s see an additional log file; can you paste the output of the following, please?

cat /opt/rockstor/poetry-install.txt

This sounds like a recent update issue in our testing channel so the additional information above should help us confirm/infirm that.
Don’t hesitate to share as much information about your system and what has been done on it; you just never know what could prove relevant and useful.


I ended up finding your post that guided one through how to fix the services of rockstor-pre and rockstor not working and this was all around python3 from python2 upgrade. I downloaded the iso that was the top level item on the website yesterday, burned to usb and installed. It was the leap iso. Leap15.4-4.5.8. On downloads page, top item. After installed I hit update and the system broke. GUI said it was doing an update but my attached monitor showed no activity on console. Decided to trust it and rebooted. Looked fine but there was no webgui available even though console said to log in on these addresses. At this point I didnt see your post… I reformatted and started over. This time when I went to do the update I looked at attached monitor and saw same lack of activity. Once web gui broke post update I manually send the zypper up --no-recommends command and performed the update that way. On reboot I followed your post for fixing the no web gui due to python2 update to python3 and I was up and going. I didnt see what I needed in the available rockons. No music manager that is currently active. Lidarr would be a suggestion. Heimdall was the other missing part. The rockons development link was too long for me to want to try building myself. Portainer would also be a worthy suggestion. Makes quick work of that. I went back to DSM via a usb stick mod. In doing that I found out my motherboard is on the edge of failing. Suddenly I lost ability to boot EFI. Not sure if there is valid concern on the upgrade or not at this point due to my hardware. In the end I want to move to a podman rootless config. May have to build my own to get it. Redhat and opensuse are not using docker and the shift away from root containers is valid and active,. please consider a feature request. The gui on rockstor is functional but not very attractive when compared. Possibly another thing I felt when going back to DSM.

This can be closed. I dont see the control to do it myself

@darylk thanks for the input.
Do you not consider Sonarr active anymore as a specialized music manager (since you were proposing Lidarr)? Heimdall is possibly a good suggestion.
Since all of these are available as images, it should actually be fairly straightforward to build a Rockon json file based on the existing Sonarr Rockon that we already have, and to have these added to the Rockon library (officially or roll-your-own).
As you know, we are community driven and rely on recommendations either here on the forum or in a github request (Issues · rockstor/rockon-registry · GitHub) to add new Rockons. Portainer is not really offered at this time in the repository, as it conflicts somewhat with the Rockon philosophy of managing your containers/apps in one place. Portainer would essentially split that responsibility. Though I’ve also built my own Portainer rockon (again, fairly straightforward) as have others, that prefer to have Portainer manage all container images, instead of the Rockons offered. The intent of the Rockons is to make installing relevant applications with minimal configuration. Portainer obviously offers way more flexibility, but also a better understanding of how containers operate and need to be set up. So, it’s that balance.
As for your UI comment, since the focus has been to move from the (now deprecated) CentOS to OpenSUSE, and the development resources are very limited, not much mind share has been available to focus on the UI. Once the major building blocks (as @phillxnet has mentioned in other threads and update logs) have been brought up to par, we can start addressing UI elements, additional net-new functionality and the likes. But, in the meantime, aside from the current core developers @phillxnet and @Flox we have to rely on other contributors if we want to accelerate the updating of both the back and front-end pieces.
So, in order to provide continuity on the Rockstor appliance, and before we enter a discussion on whether Podman is the greatest thing since sliced bread (and it very well might be), we need to get the other items aligned.
May be in the future you will take another look here and see whether it can fill your needs. Good luck!


A fault I ran in to with my introduction to containers was that my first container launched was portainer. It is what I learned on. Didnt read through the docs enough on that to realize generic linux server compose examples would be possible. The way it’s worded it sounded like dev work.

I will most certainly return as I learned on Suse 7.4 professional as my first intro to Linux and Rocstor has more merits in my mind than truenas as popular as it is. I have another project worth asking about. Jellyfin works well with transcoding but most dsm os’s dont put a /dev/dri in place. Considering I own an nvidia Tesla card this is tragedy and how I ended up on Rockstor.

Is it possible to put an nvidia driver in place to support a p4 card? I dont think I have seen anyone get a Docker working that uses nvidia on OMV. Many changes in OMV6. Most docs I fond on area about OMV5.

Moving something like this to a different OS is no minor undertaking. Completely understand the focus.

@darylk, there seems to be the option to create the container so it respects the nvidia GPU, looking at linuxserver’s documentation:

and specifically:


Hardware acceleration users for Nvidia will need to install the container runtime provided by Nvidia on their host, instructions can be found here

We automatically add the necessary environment variable that will utilise all the features available on a GPU on the host. Once nvidia-docker is installed on your host you will need to re/create the docker container with the nvidia container runtime --runtime=nvidia and add an environment variable -e NVIDIA_VISIBLE_DEVICES=all (can also be set to a specific gpu’s UUID, this can be discovered by running nvidia-smi --query-gpu=gpu_name,gpu_uuid --format=csv ). NVIDIA automatically mounts the GPU and drivers from your host into the jellyfin docker container.

In order to make this work within the Rockon framework is to augment the existing jellyfin json file with the additional variables listed above and present it to the Rockon page as a new Rockon using the rockons-metastore directory, as described here:

To experiment with a successful load/transcoding you could of course first test it directly just with the docker command line …
I unfortunately can’t help with any practical tips in this case, because the only transcoding I am using is the Intel QuickSync (on the Plex Rockon) and I don’t have any nvidia cards installed currently. Maybe someone else on the forum has had some more experience in that space (even if it wasn’t with jellyfin specifically).


Decided to try a different path. Got to be honest. After looking at rockon development and the example json I installed truenas just to run into hostpath smb issues. Then I bought unraid and I am not very happy there either. They advertised zfs support but its not as advertised. That and the nvidia card I bought was broken so i will just try to use intel gpu for jellyfin.

Is there a way to use portainer and not screw things up in Rockstor? Would rather have a compose interface.

@darylk, yes you can install Portainer directly, bypassing Rockstor. Or (the way I played with it) you can whip up a quick custom json for the Rockon and run it from there …

last time I played with it was in 2022, so no guarantee this will work:

	"Portainer_dw": {
		"website": "",
		"version": "1.0",
		"description": "<strong>Advanced Users Only!</strong> Use at your own risk.<p>Portainer is a lightweight advanced management UI which allows you to easily manage your Docker host or Swarm cluster.</p> <p>Based on the official Portainer docker image: <a href='' target='blank'></a>",
		"more_info": "<h4>Documentation</h4><p>Please refer to Portainer's documentation for details on its functions: <a href='' target='_blank'></a><h4>Important points for proper function with Rockstor</h4><p>Portainer includes a lot of features and brings new possiblities to manage your docker environment. Nevertheless, please note that it is running alonside Rockstor, meaning that some conflicts might arise. For instance, it is important to note that all volumes automatically created and managed by Portainer will reside inside the Rocstor share designed as the Rock-ons service's root. It is thus recommended to create shares from Rockstor's webUI first, and then mount them as volume when creating a new container from within Portainer.</p>",
		"containers": {
			"portainer_dw": {
				"image": "portainer/portainer",
				"launch_order": 1,
				"opts": [
				"ports": {
					"9000": {
						"description": "Portainer WebUI http port. Suggested default: 9000",
						"host_default": 9000,
						"label": "WebUI port",
						"protocol": "tcp",
						"ui": true
				"volumes": {
					"/data": {
						"description": "Data share for Portainer information. Share should be associated with root user/privileges, as the container runs as root",
						"label": "Data Storage"

This way, you can return to Rockons or at least remove any Portainer leftovers (e.g. before an update/upgrade, etc.) and keep the OS clean. Of course, you can also just run the Portainer container outside of the Rockon framework …


One Post Script question: have you tried the jellyfin Rockon just with the Intel GPU portion (by entering the device path? Or is your question around Portainer for other apps that you’re looking for?

1 Like


I only use standard docker containers, not rockons. But you need to activate rockons for them to install.

Only thing you really need to install through terminal is portainer, rest can go through portainer stack (docker compose).

I have many containers running without any problem.

I you want to go this way, make a share, preferably outside os disk, for rockon. Turn on rockon and point to the share. That’s it. Then install portainer through terminal. No need for json file, just docker cli.

And, don’t delete any snapshots! Discovered that the hard way :smiley:

If any problems, turn off rockon, delete every file in rockon share and start again. And keep your config files for containers in another share.