Ancient FreeNAS Box, unable to recover root password

[Aaron C. de Bruyn]

We have an old FreeNAS server sitting in our archives that had data for an office that closed years ago.
A few days ago we were told we needed data from the machine.
I don't recall which version of FreeNAS is was running, but GRUB gives me what appears to be a git commit SHA and a date of 2017-02-19.
Amazingly it boots with the only failure being an intent log drive.

The box was locked down so we don't get the menu on boot-up--just a login prompt.
We've gone through all our documentation and have thrown every password we can find at the root account. No dice.

I finally decided to reset the root password by booting into single-user mode and running:

Code:

mount -urw /
mount -a
passwd root
<enter a new password>
<confirm the new password>
python /usr/local/www/freenasUI/manage.py changepassword root
<enter a new password>
<confirm the new password>
sync
exit

The new password doesn't work to sign in at the console.
I can't get to the web interface because I have no idea what the IP for the box is at the moment, and it's not in a decent spot where I can do some packet inspection to try and grab the IP.

Am I missing some magic way of resetting the root password on FreeNAS boxen? Those are the two options I see throughout the forums.

 

[Chris Moore]

Is the pool encrypted?

 

[Chris Moore]

If the pool is not encrypted, you can simply make a new installation of the OS and import the pool. The storage pool should be independent of the boot media. If you have physical access to the system and the pool is not encrypted, it is trivial to access the data.
Not knowing the password, I would have started with that.

 

[Aaron C. de Bruyn]

Hey Chris,

The pool is encrypted.
I do have backups (allegedly) of the key, passphrase, and recovery key for the pool, so unlocking after a reinstall shouldn't be a problem.

That seems like the fastest option at this point, but I guess I'm curious why I can't reset the password.
I see that /etc/ix.rc.d/ix-password touches /etc/master.passwd...but I'm not sure if that's just run when you update an account in the web GUI, or if that generates the file on boot. Tweaking it to leave the password field blank didn't help me.

There's obviously some black magic I'm missing...

 

[Chris Moore]

That seems like the fastest option at this point, but I guess I'm curious why I can't reset the password.

Because the person that setup the system locked the console. The console is where the password would be reset. There is no booting a FreeNAS into "single user" mode like you attempted to do. That is just not a thing in FreeNAS.

There's obviously some black magic I'm missing...

FreeNAS being an appliance that was built on FreeBSD, there are core components that appear to be standard, but anything that is changed through the command line is reset based on the config database record and the config database is edited through the middleware that is accessed by the menu on the console and by the GUI. If you don't edit the config database, any change will only affect the running session. The system is completely rebuilt at every boot based on the config db.

 

[Aaron C. de Bruyn]

anything that is changed through the command line is reset based on the config database record and the config database is edited through the middleware that is accessed by the menu on the console and by the GUI

Shouldn't that mean that running

Code:

python /usr/local/www/freenasUI/manage.py changepassword root

would update the config database that then regenerates the files on boot? Or does the changepassword command not update the same fields used to generate /etc/master.passwd?

 

[Aaron C. de Bruyn]

Found it.

Code:

mount -urw /
mount -a
python /usr/local/www/freenasUI/manage.py dbshell
update account_bsdusers set bsdusr_unixhash='' where bsdusr_username='root';
sync
exit

Sign in as root with no password.

EDIT: This won't change your GUI password. For that you'd have to run

python /usr/local/www/freenasUI/manage.py changepassword root

Obviously, you should probably immediately go to the web GUI and make sure your root user has a valid password for security reasons.

 

[sorousheta]

Man, I think u save my life.. :D.. its work on my laboratory. and should be work on my department servers.

tnx Bro.