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: 192.168.1.100, server: ~^(?.+)$, request: “GET /static/js/lib/json2.js HTTP/1.1”, host: “192.168.1.107”, referrer: “https://192.168.1.107/login_submit”
192.168.1.100 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 : https://rockstor.com/
Summary : Btrfs Network Attached Storage (NAS) Appliance.
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)
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.
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.
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.
@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:
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
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.
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.
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.
@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.