[Bug?] Renamed Admin User Cannot Use Console Restore (#15) While “admin” Can (ZFS Mirror Setup)

serengeti

I’ve encountered an issue on pfSense (which happens to be running on a ZFS mirror across two drives) where a renamed admin account –e.g., "userx" logged in via SSH, cannot successfully restore the configuration from the console menu (Option #15). However, if I SSH in as the default “admin” user, everything works perfectly. I suspect it might have to do with the "userx" account not having file system write permission despite being an admin?

Environment & Symptoms
• pfSense Version: CE 2.7.2-RELEASE
• Filesystem: ZFS mirror (two drives)
User Setup:
• Renamed the default “admin” user to something else (e.g., “userx”).
• Ensured “userx” is in the admins group with WebCfg - All pages plus Shell account access. In the WebGUI, it shows “member of group admins”

What Happens
1. Logging in as the renamed admin "userx" (over SSH):
• It drops me directly to a shell rather than the pfSense menu (i.e., /etc/rc.initial does not run automatically).
• When I manually run the menu ( /etc/rc.initial ) and choose Option #15 (Restore a configuration), I get a fatal PHP error:

PHP Errors:
 PHP Fatal error:  Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /etc/inc/config.lib.inc:1000
Stack trace:
#0 /etc/inc/config.lib.inc(1000): fwrite(false, 'a:30:{i:1737077...')
#1 /etc/rc.restore_config_backup(27): cleanup_backupcache()
#2 {main}
  thrown in /etc/inc/config.lib.inc on line 1000
 PHP Fatal error:  Uncaught TypeError: fwrite(): Argument #1 ($stream) must be of type resource, bool given in /etc/inc/config.lib.inc:1000
Stack trace:
#0 /etc/inc/config.lib.inc(1000): fwrite(false, 'a:30:{i:1737077...')
#1 /etc/rc.restore_config_backup(27): cleanup_backupcache()
#2 {main}
  thrown in /etc/inc/config.lib.inc on line 1000

The restore fails.

Logging in as the default “admin”:
• /etc/rc.initial launches the console menu immediately.
• Selecting Option #15 works perfectly—no errors, and the config restores normally.

Why It’s Confusing
• Even though the renamed admin account "userx" has full admin privileges in the WebGUI (member of the admins group, plus User - System: Shell account access), it cannot perform the same console restore that the default “admin” account can.
• This behavior is at minimum inconsistent: the console environment apparently treats the default “admin” user differently from other fully privileged users.

Request / Questions
1. Is this expected behavior or a bug?
2. Could the console scripts be explicitly looking for “admin” or “root” only, thereby skipping environment setup for renamed users?
3. Can we unify the privilege checks so that any user in the “admins” group (with full privileges) has the same console capabilities?

Thanks for looking into this. It would be great if pfSense’s console environment recognized any user with full admin privileges for tasks like config restores—even when the username is not “admin.”

Additional Details (if relevant)
• Confirmed that disk space is plentiful and ZFS pool is healthy.
• mount output shows the system is not read-only.
• The error specifically appears in /etc/inc/config.lib.inc around the cleanup_backupcache() call.
• Once I switch back to logging in as “admin,” the problem disappears.

Any guidance or confirmation would be greatly appreciated!

PS. This user encountered the same problem (5th message down)

stephenw10

That is the expected behaviour, you need to actually be admin/root to use a number of the console menu features.

But the PHP error seems like it could be avoided. If a bug exists it's that the error handling should be better.

serengeti

@stephenw10 Thanks for the response.

• The WebGUI can be misleading because it allows disabling the default admin account and creating a new account with “full” privileges—without warning that certain console menu features will not work unless you log in as the original admin.

• Tom Lawrence’s pfSense setup videos imply that disabling the default admin user is a best practice, which can unintentionally lead to this issue if someone later needs to restore from the console.

• It’s also unclear if the periodic backups that pfSense creates are accessible to the newly created “admin” account, or if you must use the console menu (and thus the default admin user) to restore them.

• Because of this, it’s critical for anyone who disables the default admin account to make off-box backups. Otherwise, they might end up with backups they can’t easily restore via the console.

Gertjan

@serengeti said in [Bug?] Renamed Admin User Cannot Use Console Restore (#15) While “admin” Can (ZFS Mirror Setup):

• Tom Lawrence’s pfSense setup videos imply that disabling the default admin user is a best practice, which can unintentionally lead to this issue if someone later needs to restore from the console.

Very true.
Valid for multi user systems, like mail web game whatever servers. Mostly devices that are somewhere in a data center, direly connected to the net.
But not a firewall, the one siting right next to you.
With a firewall, like pfSense, it is easy to, for example : limit admin access only to "LAN2". Block ssh and GUI https access on all other NICs, and done.
If needed, lock you pfSense in a safe, so now the LAN2 is physically protected.
You have to protect the console access anyway ^^

pfSense doesn't need 'multi access admin' access. There is no need to create others users.
It's like the left seat in a car : the one sitting there has the keys, the one sitting there is driving.

You can, if needed, and if SSH is activated, protect SSH without user (admin) & password, and use only certs.
The GUI : just pick a hard password, and don't let the web browser save it : you'll be fine.
pfSense doesn't contain any credit card numbers, neither any other type of data that is important or needs to be protected. So, just one password will do it.

serengeti

@Gertjan

Multiple Admins & Auditing
• Many organizations require separate admin accounts for logging and auditing. Having one shared “admin” makes it impossible to track who performed a change.
• pfSense is used in enterprises and regulated industries, so a single-account setup may not meet compliance requirements.

pfSense Does Contain Sensitive Data
• pfSense holds VPN credentials, preshared keys, etc. A compromised firewall can compromise the entire network.
• Saying “it doesn’t store credit cards” misses the fact that firewall-level access is critically important to protect.

Console Features vs. GUI Permissions
• The GUI explicitly allows renaming or disabling the default “admin,” suggesting this is fully supported.
• Yet the console restore (#15) and other features fail unless you use the original “admin” or root. This mismatch is confusing and should be documented or fixed. Its a UI/UX issue.

Large Deployments & Hosted Environments
• Some users run pfSense in remote data centers or have multiple admins who need unique logins.
• Telling them to “lock it in a safe” only applies to small, on-prem deployments.

Backups & Disaster Recovery
• If the default “admin” is disabled, it’s easy to assume your new “admin” account can restore from the console—until you discover it fails in an emergency situation. That can be disastrous.

User Expectations & UI Clarity
• Users see an “admins” group or “WebCfg – All pages” permission, "User - System: Shell account access" permission, and expect full parity with the default admin.
• The hidden requirement to use the original “admin” or root for certain console functions leads to surprises, confusion, and potential downtime.

stephenw10

I agree it should have better documentation. Open a feature request/ bug report here: https://redmine.pfsense.org/