Suddenly unable to log in to web interface

been using rockstor for maybe a month, no real issues. this morning I tried to log into the web interface and it tells me wrong password. I am able to access the smb shares, and I can ssh with my created username. I can log into the physical terminal with root but not ssh? I think that is by design perhaps, or maybe I did that I dont recall. after ssh with my username I can su root fine. I can access several smb shares with different usernames, so authentication is not the problem. I am not finding much in the logs, except in /var/log/nginx I get this line when I try to log on the web interface. [error] 1701#1701: *2 open() “/opt/rockstor/static/js/lib/json2.js” failed (2: No such file or directory), client:, server: ~^(?.+)$, request: “GET /static/js/lib/json2.js HTTP/1.1”, host: “”, referrer: “ is the computer im trying to access the web interface. and the x.x.x.107 is my rockstor ip.

is there a specific log file I need to get information from? ive looked in the log files in /opt/rockstor but theres nothing interesting, and surprisingly little in them to begin with. I have looked in /opt/rockstor/static/js/lib and json2.js is indeed missing.

help please! please note I am fairly green with linux, but have 22 years sysadmin experience.

@jihiggs welcome to the Rockstor forums.
Which version of Rockstor are you running? Since you don’t have access to the WebUI, you can run this in your terminal:

zypper info rockstor

that should show you what’s installed and which version, like this:

Information for package rockstor:
Repository     : Rockstor-Testing
Name           : rockstor
Version        : 4.5.9-1
Arch           : x86_64
Vendor         : YewTreeApps
Installed Size : 9.5 MiB
Installed      : Yes
Status         : up-to-date
Source package : rockstor-4.5.9-1.src
Upstream URL   :
Summary        : Btrfs Network Attached Storage (NAS) Appliance.
Description    :
    Software raid, snapshot capable NAS solution with built-in file integrity
    Allows for file sharing between network attached devices.

The error you describe seems to not be necessarily related to your issue. When checking the error log:
/var/log/nginx/error.log I also can see that same message, however my WebUI works without a problem (i.e. logging in, navigating, etc.).

Just to clarify, you do get the actual Rockstor login screen, however your login attempt fails (wrong password), correct?

Very dumb question likely, but did you happen to change your keyboard mapping recently on your 192.168.100 machine (say from EN to DE) which could cause a password to get messed up when typing blindly (e.g. z vs. y)? Just had to ask (speaking from experience) :slight_smile:
If this was the case, you wouldn’t see this problem via your SSH terminal program (if, e.g. you’re using PuTTy) since there the keyboard mapping is driven by what Rockstor is set to, not your local machine.

Correct, web interface brings me to the rockstor login. I have typed the password and pasted. Have not changed my keyboard. Nothing changed from last night.

1 Like

Thanks for the validation. On your screenshot I see one other piece of information, you’re running this on the Tumbleweed build, correct?
Were there any of the daily available TW updates applied to your system?

Just to report back. I have the test TW instance running on a VM, albeit already upgraded to 4.5.9-1. I applied the latest TW changes to it, but am not running into the login issue on the UI to date. For clarification, I am using a separate user for the webui (like admin) from the one I use for the terminal (root).
Not that this likely helps you, unfortunately, but wanted to add this observation for others to contemplate.

Current TW version info:

fresse:~ # cat /etc/os-release/
NAME="openSUSE Tumbleweed"                                                                                                                                                                                                                                              
# VERSION="20230503"                                                                                                                                                                                                                                                    
ID_LIKE="opensuse suse"                                                                                                                                                                                                                                                 
PRETTY_NAME="openSUSE Tumbleweed"                                                                                                                                                                                                                                       

Yep, tumbleweed. No daily builds. Haven’t even done a supper update in weeks

Looked back through my history file last night and a couple days. I did some work in the passwd file and played with authorized keys for some other accounts. But it all looks fine to me. It would affect shell logon if I broke something.

The only thing I can think about is, that if the user for the web-UI is set to be “managed by Rockstor” that it could have an impact if you muck about with the passwd file and authorizations.

screenshot for reference, since you don’t have UI access currently:

But to answer that we probably need @phillxnet’s expertise …

@jihiggs Hello there. What Hooverdan said plus:

Correct, Tumbleweed JeOS/Minimal-VM images tends to disable ssh root login now by default now:

Fix/re-config is to enable this capability explicitly via:

Tumbleweed (x86_64 only) default does not permit root login via ssh so locally we do:

    touch /etc/ssh/sshd_config.d/PermitRootLogin.conf
    echo "PermitRootLogin yes" >> /etc/ssh/sshd_config.d/PermitRootLogin.conf
    systemctl reload sshd

The above duplicates what we find by default on our Tumbleweed aarch64 images.
Where this file contains the following:

    # Allow root login on ssh
    PermitRootLogin yes

Unfortunately authentication is a little more nuanced than that, I.e. smb / file level / user/group etc. And Django’s own user db as well as Postgesql’s db etc. But still.

No, we haven’t had any other reports of this as of yet (doesn’t mean there arn’t any pending of course).
And thanks for the follow-up investigation: it’s what our testing channel is all about.

Yes, this is very important. The ‘root’ users must not be used for the Web-UI. The Web-UI use is strictly a regular use from the systems point of view. We recently updated our docs on that point after there was some confusion about the Web-UI user some how being confused with an admin (root in linux land) user on the system:

An unprivileged linux user will also be created by this step (UID=1000 GID=100).

That’s an odd one as it doesn’t look to be part of a regular Rockstor install. Did you install this system via our installer? do you have any other custom config, as in why were you command line altering user config:

But agreed re:

I’m unfortunately not able to shed much light on this actually. As @jihiggs VM install demonstrated, by default we do appear to be mostly functioning on our development (forward looking) Tumbleweed instances, but there is work to be done on the ssh side due to upsteam changes detailed by @Hooverdan in this issue:

@jihiggs Keep us posted on your investigations. And keep in mind the notice we have re our Tumbleweed on the Downloads page:

Development/Advanced-user/Rescue use only

it’s our window on the future as it were. But it’s mainly just the ssh issue above that’s known dysfunctional actually so if you can cope with that it’s great to get feedback, such as you have give, on how things are behaving. Plus stuff gets fixed quick in Tumbleweed; but equally it also gets broken frequently!! But nice for latest btfs etc.

Hope that helps. And thanks for the ongoing report.

1 Like

@jihiggs Just a quick additional note,

We do have a command line re-set procedure that wipes all config and resets the database etc to that of a fresh install. See our developer docs in the following section:

For the details. As stated there it will return your system, from the Web-UI and backing database point of view, to this step in the install:

Maybe be overkill but may get you over having to do a reinstall if this system need to be back-in-action as it were. But you will then have to start from scratch but can of course re-import the pool, but without a config save (I’m assuming non is available) you will have to manually reconfigure all your smb shares etc. It will likely just overwrite identical settings you already have but will re-instate those settings as ones Rockstor manages. But this is not as clean as a re-install as things like users that were managed by Rockstor (as they were created from the Web-UI) will not be assumed as managed any longer as they existed before it was setup as it were.

Just a thought, and to present this as a know option if this serves your purposes. But really a re-install is cleaner. Unless you are keen to track down further what may have happened. But if authentication is changed at the command line level all maner of knock-ons can ensue and can then end up absorbing all developer time on what is extra appliance land really. We don’t purposefully cater to all possible configurations, even within btrfs itself: and this is purposefull. If we did we would be the command line itself. The ‘Appliance’ element of what we try to do here necessarily limits our scope, but that is in-turn expanded by such reports are yours so do keep up the feedback as it’s all good stuff.

My apologies for not being of more help.

1 Like

ok, I cant say what happned… I have an account named “james” which is the rockstor admin account found in the gui, system/users. this password has not changed, I know this because of the audit trail in my password manager, I set the password once and didnt change it. somehow the rockstor web ui side of things became “out of sync” with the “linux” side of the password for this account. I could still use this james account to log into ssh and physical terminal, but not the web ui. your suggestions lead me to try the tool in /opt/rockstor/.venv/bin to reset the password for “james”. I thought perhaps the linux side and the rockstor ui side were not actually the same account as I believed. but turns out they really are, since I used this password to log on to the web ui, and ssh. the question is why did it suddenly stop working for the ui but not ssh. I still have much to learn about linux authentication.

1 Like

@phillxnet on this one, I mentioned (buried further up) that I can also see that message in the nginx log, my installation was from the published TW iso (4.5.8-0) before I recently upgraded it to the latest one.

I checked it on the Leap 15.4 version of 4.5.9-1, too, and there as well this error message shows up in the nginx error logs.


@Hooverdan Thanks for the following:

My apologies for missing that entirely - pulled in a number of directions currently !

Do you fancy making an issue for this, and crediting also @jihiggs. It looks to be harmless but I’d like to know exactly what’s going on with that log entry.

Again, my apologies all-around for missing your confirmation on that one. Still it’s a bit odd. Not our priority but it would be good to have it as an issue.



@phillxnet, certainly, here is the new GitHub issue, please adjust as needed: