I can not find the log in the /opt/rockstor/log/ directory. The contents of the rockstor.log do not have any entries related to the install.
Please tell me where I can find it so I can post the logs.
Rockstor v3.9-1-16. I upgraded from a fresh install last night from latest download found here then.
Hi @PDXUser, and welcome!
I’ll try to help as much as I can and see where the problem lies.
The rockstor log file can be found at the following location: /opt/rockstor/var/log/rockstor.log. You do seem to have found it, however, as you state its content do not have entries related to the install; were you referring to another log file?
Note that we have a built-in tool to access all relevant logs; it can be found under “System > Logs Manager”.
Going back to your issues with rock-ons install, could you provide a bit more information on the context?
To rule out any problem related to updates, and because you probably had to go through a lot of system updates, did you reboot after all the updates?
Sorry for all the questions. but that will hopefully help get a better idea of what is going on and help resolve it faster.
Thank you for your help! I made a back up of the rockstor.log file and emptied the original to make it easier to track the install. This is the capture I have after the attempted install of Sonarr:
[06/Apr/2019 10:03:35] ERROR [storageadmin.views.rockon_helpers:124] ‘NoneType’ object has no attribute ‘name’
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 121, in install
generic_install)(rockon)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 209, in generic_install
cmd.extend(vol_ops©)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 179, in vol_ops
share_mnt = (’%s%s’ % (settings.MNT_PT, v.share.name))
AttributeError: ‘NoneType’ object has no attribute ‘name’
For Radarr
[06/Apr/2019 10:07:59] ERROR [storageadmin.views.rockon_helpers:124] ‘NoneType’ object has no attribute ‘name’
Traceback (most recent call last):
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 121, in install
generic_install)(rockon)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 209, in generic_install
cmd.extend(vol_ops©)
File “/opt/rockstor/src/rockstor/storageadmin/views/rockon_helpers.py”, line 179, in vol_ops
share_mnt = (’%s%s’ % (settings.MNT_PT, v.share.name))
AttributeError: ‘NoneType’ object has no attribute ‘name’
For Both of the installs, It will go to the installing animation, then it goes away with no error messages and software is not installed.
I have been able to install other Rock-Ons with no issue.
Thanks a lot for the information, that is very helpful and seems to indicate a problem with the share(s) used for these rock-ons. Specifically, it looks like an empty share name is passed to the install code… curious.
Anything special about the shares you chose for these two rock-ons vs the other rock-on(s) you were able to install without error?
I don’t have access to my test machine right now so I unfortunately can’t test the install myself, but in the meantime I figured I’d ask.
NOTE: I tried on a more recent version of Rockstor and the install did go through with the intended values:
Running command: /usr/bin/docker run -d --restart=unless-stopped --name radarr -v /mnt2/r_movies:/movies -v /mnt2/r_conf:/config -v /mnt2/r_dl:/downloads -v /etc/localtime:/etc/localtime:ro -p 7878:7878/tcp -e PUID=1000 -e PGID=1000 linuxserver/radarr
Would you be able to share a screenshot of your final rock-on install settings, by any chance (the one including the table summarizing all settings)?
I was able to get it installed but it does not show when I go to the URL. (http://192.168.1.215:8989/).
]# service sonarr status
Redirecting to /bin/systemctl status sonarr.service
● sonarr.service - Sonarr Daemon
Loaded: loaded (/etc/systemd/system/sonarr.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2019-04-06 11:13:36 MST; 3h 16min ago
Main PID: 4907 (code=exited, status=2)
Apr 06 11:13:36 nas systemd[1]: Started Sonarr Daemon.
Apr 06 11:13:36 nas mono[4907]: Cannot open assembly '/opt/sonarr/bin/NzbDr...y.
Apr 06 11:13:36 nas systemd[1]: sonarr.service: main process exited, code=e...NT
Apr 06 11:13:36 nas systemd[1]: Unit sonarr.service entered failed state.
Apr 06 11:13:36 nas systemd[1]: sonarr.service failed.
Hint: Some lines were ellipsized, use -l to show in full.
I was able to install though, changed the settings for Config, Download and Media directory in setups to “root” instead for setting Config to “home” and Media to “Media” (Which is the drive where Media is), and and Download to “Media” which seem to make it not work.
However, it doesn’t want to launch based on the errors in the quote.
I was able to get Radarr working too. It took a while for it to load. But I gave Sonarr about 2 hours to launch. and still not working.
Browser is Firefox and new failure code if this helps:
service sonarr status
Redirecting to /bin/systemctl status sonarr.service
● sonarr.service - Sonarr Daemon
Loaded: loaded (/etc/systemd/system/sonarr.service; enabled; vendor preset: disabled)
Active: failed (Result: exit-code) since Sat 2019-04-06 11:13:36 MST; 3h 22min ago
Main PID: 4907 (code=exited, status=2)
Apr 06 11:13:36 nas systemd[1]: Started Sonarr Daemon.
Apr 06 11:13:36 nas mono[4907]: Cannot open assembly '/opt/sonarr/bin/NzbDrone.exe': No such file or directory.
Apr 06 11:13:36 nas systemd[1]: sonarr.service: main process exited, code=exited, status=2/INVALIDARGUMENT
Apr 06 11:13:36 nas systemd[1]: Unit sonarr.service entered failed state.
Apr 06 11:13:36 nas systemd[1]: **sonarr.service failed**.Good… we’re making progress.
I’m not familiar with Sonarr, but the error below let’s me want to verify the shares setup isn’t the culprit. Would you be able to share a screenshot of the rock-ons summary table? (click on the little wrench icon next to the ON/OFF toggle)
Apr 06 11:13:36 nas mono[4907]: Cannot open assembly '/opt/sonarr/bin/NzbDrone.exe': No such file or directory.
I am going to have to move on - Software looks good, however a bit too buggy for me. I reinstalled the server, upgraded to latest, and upon installing Radarr, it killed the web GUI. I appreciate the help however. I might be back later.
@PDXUser, I can chip in on this one. @Flox has essentially got to the root cause of your issue. You are using the ‘root’ share instead of creating one specifically for the purpose. This is a usability bug and is now fixed in our latest code which is actually in stable not testing, see the intro in the following thread:
in short testing stopped at 3.9.1-16 which was equivalent to what would have been 3.9.2-0 stable. We are now on 3.9.2-48 stable as of 2 days ago.
However if you did in fact update to stable:
Then it is best to confirm your actual running version via
yum info rockstor
As going from testing to stable can end up showing a stable version (3.9.2-#) in the Web-UI but actually not installing it. But this doesn’t happen if you go straight to stable from the iso.
In stable channel releases it is no longer possible to select the ‘root’ share as it no longer appears in the Web-UI. We showed it previously (so appears in older testing) but due to work involved in moving to openSUSE a bug was found that where by this was not /root, as many would reasonably suspect, but actually ‘/’ and of course this is very bad. Especially if a rock-on is given that as a ‘share’ to use. Hence the error @Flox wondered about and hence your system breaking when you gave a Rock-on (docker) direct access to the root of your system.
This removal of surfacing root was in the following changes:
https://github.com/rockstor/rockstor-core/pull/1935
against the following issue:
https://github.com/rockstor/rockstor-core/issues/1931
It was a bad show on our part but has now been fixed since stable release version 3.9.2-24 released June 2018.
So in short we previously shouldn’t have surfaced ‘/’ offered as “root” share name: which we don’t in latest code. And the UI should have guided you better on creating specific shares for each rock-ons requirements, maybe those tooltips should be text under/against each text box (@Flox your thoughts on this idea would be welcome).
I.e. in the Rock-on sonar definition we have:
This advise shows as tooltips and advises in turn to create the following shares:
This is crucial advise and if not followed, and on older testing code, can lead to catastrophes if the then offered ‘root’ is selected. Apologies for our slow progress in releasing iso’s with this fix in but we are hoping to resurrect the testing channel once we re-establish ourselves on openSUSE and have build up more resources. There is also planned a fresh image based iso for the openSUSE installs when they are ready. This will of course have the latest code on release.
There is also the Rock-ons (Docker Plugins) doc section as you may also have not followed the advise there to create a share specifically for the Rock-ons system component.
Much usability work for us to do on our side but I would invite you to read the Rock-on install wizard tool-tips as presented and to peruse that doc section linked and then re-install, as you system is likely toast, and give it another go.
Let us know how it goes if you do end up giving us another trial. Thanks in any case as your input here has helped to reinforce a usability shortfall that those tooltips represent as if one doesn’t look at them (easily missed) then it does lead to a less desirable state; especially with our older code releases.
Hope that helps and good luck in your NAS experiments going forward.