"Interfaces" menu in the GUI returning errors for several sub menus

[ctdenney]

I have recently installed OPNSense 21.7 on a PC Engine APU2e2. Everything seemed to go well during install, I'm able to reach the GUI, and have access to the internet. However, from the GUI, if I select the "interfaces" menu and then try to access the [LAN], Assignments, Overview, or Diagnostics/Ping submenus, I get the following error:

Fatal error: Unknown: Failed opening required '/usr/local/opnsense/www/index.php' (include_path='usr/local/etc/inc:/usr/local/www:/usr/local/opnsense/mvc:/usr/local/opnsense/cotrib:/usr/local/share/pear:/usr/local/share') in Unknown on line 0

This error has persisted across several reinstall attempts. I'm sort of at my wits end here.

Thanks for any help.

[franco]

Fix by forcing a reinstall of the core package?

# opnsense-revert opnsense


Cheers,
Franco

[ctdenney]

Successfully ran that command, did a reboot, and the problem persisted. Also ran the updater through the GUI and also didn't fix the problem 

In case it matters, that index.php file exists at the stated folder and I was able to open it with nano/vi through the shell. Is it possible it's some kind of permissions error?

[franco]

Strange, though that would mean the health audit will show a similar image of an "ok" system so the question is: how are you triggering this? Special permission assigned to separate user? Some sort of proxy or script triggering this?


Cheers,
Franco

[ctdenney]

If you mean, how am I triggering the error, it happens when I load up the GUI at the default IP address (connected to the machine via an ethernet cable), log in as root, and try to click and of the above mentioned menu items.  The problem occurs immediately after a fresh install (during which the internal drive was formatted, according to the install wizard).

To answer my own question about permissions, I just checked the ownership of the index.php file with

Code: [Select]

ls -l and it returned as "root wheel" which I assume is the correct, default ownership condition, so that doesn't seem likely to be the issue.

Here is another idea that might be causing it.....when doing the installation process, if I choose the default install option (rather than the "extended" option I think it was called), I got a warning about the amount of RAM available and copying over the relevant files (the box has 2 gigs of ram). The extended version of the install process does not bring up this warning, but is it possible that some files were not able to be copied over? Although I'm not sure why that would still persist after your recommended fix and/or the upgrade procedure.

I'm really just spitballing here as this is all way outside my wheelhouse.


-edit- I realize this sort of contradicts my original statement of "everything seemed to go well during install", but the warning was the reason I avoided the default install option and chose the extended one, and I assumed that the lack of warning during that process meant that I had avoided the issue.

[franco]

Interesting... can you access the console, e.g. via SSH? In the console menu option 12) type "h" at the prompt and run the health check by confirming with enter.

If it's a faulty install it should tell us. Also "df -h" may also shed some light on the situation (disk full maybe?).


Cheers,
Franco

[ctdenney]

yes, I can access the console via SSH (or serial, I enabled both through the GUI). Menu option 12 is "update from console" and when I ran it, the only prompt that came up was asking for y/n to continue. I assume that's where you meant to run "h" instead of Y/N. When I ran that, it reported everything as correct/no problems detected.


df -h says that the interal disk is only at 7% capacity (it's a 27gig drive mounted on "/"). There are three small partitions (I think? or maybe just one mounted in three places? they are all called "devfs" under filesystem (the main drive is called /dev/gpt/rootfs) and have a size of 1.0K, 100% full). They are mounted on /dev, /var/dhcpd/dev and /var/unbound/dev.

[ctdenney]

I think I just figured out a clue as to what might be going on, but I don't know enough to know what it means or what it implies about how to fix the issue (although I have a guess, maybe?)

When I was in the shell, I noticed that in the main menu, it listed two interfaces the LAN and WAN, and gave an IP address for each. The LAN was the default address listed in the docs (192.168.1.1/24) and the WAN address was a slightly different one. I have been using the LAN address this whole time, so I tried reaching the GUI via the WAN address instead of the LAN address and, after successfully logging in with the root account, all of the broken menu items worked.

My guess as to what this might mean is that maybe I don't have the interfaces assigned/configured properly? Could that explain why, when connected over the LAN address, the LAN menu doesn't work (along with several other menus). If that is the problem, would trying to use the "assign interfaces" option in the ssh menu (option 1) help resolve it?

[ctdenney]

This issue definitely has something to do with interface assignment and configuration. When I went through the automatic interface assignment protocol through the shell (via the serial connection since the interface assignment required removing all the ethernet connections), it ended up changing the two IP addresses, and the WAN address no longer worked to reach the GUI (which I gather from reading elsewhere is actually the normal behavior and access to the box via the WAN address is both not advised and needs to be explicitly activated, apparently. I'm not sure why it was working previously), and the GUI, when reached through the new LAN address, no longer displayed any of the previous errors. While I don't understand what exactly was causing the issue previously, I'm considering it resolved.

I appreciate the help.