Elusive issue | Could not handle admin ui root request

[rytz]

Hello everyone! This is my first post on this forum and it’s nice to virtually meet you. As a big supporter of small business and open source software and hardware, I was really happy to find and support OpenMarine’s OpenPlotter OS and MacArthur HAT to supplement my sailing lessons, and after purchasing the latter and connecting everything up in a basic setup, it’s going mostly right but I have run into one major issue I find difficult to describe, but I'll do my best.

My issue:

After running for many hours (a day or so), all at once I lose at least a) SSH access and b) access to the web GUI via the Signal K addresses (e.g https://192.168.0.145:3443/admin/#/dashboard) with the browser displaying error message: ‘Could not handle admin ui root request’

The only action that seems to restore full functionality is a complete reboot of the system, though oddly I still seem to be able to access Signal K data (navigation.position and IMU gyro readings are all still being updated live and seen by OpenCPN running on an Android phone over the network).

I happened to have been connected via SSH one time it happened and basic commands like ‘sudo journalctl -f’ were failing in bash due to I/O errors, again, until I restarted. I suspected that perhaps low voltage or a spike was causing issues so moved from the 12V battery to an official Raspi 5 AC power supply but the issue seems to persist. (I remembered to remove the power module before powering on with AC.)

When I first bought the Pi I did deal with a bad Samsung NVME SSD I already had that turned out to be a very elusive problem to diagnose (bad SSD) but the new Fanxiang worked right away when the Samsung didn’t so I assume it’s not the storage hardware causing the issue now, though I know that’s hard to rule out completely.

My question:

Has anyone seen this issue or know how I can diagnose what’s going wrong exactly? I have the Log Viewer plugin installed plus use journalctl but don’t see anything obvious that points to the behavior described. I’ve searched this forum and not seen anything like it or that matched the error message. I also have Debug mode enabled as outlined in the Bug Reports thread, but am not sure what output that produces.

Thanks for reading and for any help you can provide.


Setup:

Raspberry Pi 5 16GB
Fanxiang 2TB NVME SSD on
Pimoroni PCIe NVME M.2 HAT+
MacArthur HAT
    ICM-20948 IMU
    Power module
Uniden MHS338BT VHF Radio GPS w/ NMEA 0183 out

This system runs at home 24 hours a day off a 10Ah 12V sealed lead acid battery I keep on a charger but occasionally let it run off battery alone.

Software side, it runs the OpenPlotter OS Raspberry Pi image, updated to current versions of OpenPlotter and Signal K and all their respectively installed plugins.

[abarrow]

Are you seeing anything in your logs that might give you a hint as to the source of the problem?

[rytz]

Hi abarrow, thanks for your reply. I noticed that the time suddenly changed before the time I believe this last happened earlier today and there's an entry for a new server version check. Could that be the cause?

Jan 05 11:07:49 2026-01-05T19:07:49.490Z signalk-logviewer Hostname: openplotter
Jan 05 11:07:49 2026-01-05T19:07:49.491Z signalk-logviewer Not a Cerbo/Venus OS system
Jan 05 11:07:49 2026-01-05T19:07:49.491Z signalk-logviewer Checking for Victron Cerbo logs...
Jan 05 11:07:49 2026-01-05T19:07:49.491Z signalk-logviewer Attempting to read Victron Cerbo log at: /data/log/signalk-server/current
Jan 05 11:07:49 2026-01-05T19:07:49.491Z signalk-logviewer Victron Cerbo log not accessible: ENOENT: no such file or directory, access '/data/log/signalk-server/current'
Jan 05 11:07:49 2026-01-05T19:07:49.491Z signalk-logviewer Trying journalctl...
Jan 05 11:07:49 GET /signalk-logviewer/api/logs?lines=2000 200 180.304 ms - -
Jan 05 13:19:01 GET /admin/ 200 2.358 ms - 567
Jan 05 13:19:01 GET /skServer/loginStatus 200 4.001 ms - 204
Jan 05 13:19:04 GET /skServer/logfiles/ 304 3.129 ms - -
Jan 05 13:19:04 GET /skServer/debugKeys 304 1.531 ms - -
Jan 05 10:32:58 2026-01-05T18:32:58.962Z signalk-logviewer Plugin started
Jan 05 10:32:59 signalk-server running at 0.0.0.0:[object Object]
Jan 05 10:32:59 Redirect server running on port [object Object]
Jan 05 10:32:59 unable to check for new server version: TypeError: fetch failed
Jan 05 10:32:59 5 Jan 10:32:59 - [info] Welcome to Node-RED ===================
Jan 05 10:32:59 5 Jan 10:32:59 - [info] Node-RED version: v4.1.2
Jan 05 10:32:59 5 Jan 10:32:59 - [info] Node.js version: v20.5.1
Jan 05 10:32:59 5 Jan 10:32:59 - [info] Linux 6.12.47+rpt-rpi-2712 arm64 LE
Jan 05 10:32:59 5 Jan 10:32:59 - [info] Loading palette nodes 
Jan 05 10:32:59 [object Object]

To the best of my recollection (always hard to precisely identify timing of this sort of issue) the issue occurred at or after the 10:32:59 mark, so it might not be related, but those 13:19:01 entries are in the correct order so it seems like something affected the time there.

---

On closer inspection I think the time issue is unrelated. In loading the server log again just now using the built-in Signal K web GUI > Server > Server Logs, there were entries out of order similar to those in the log I posted earlier. I chalk it up to glitchy behavior.

Viewing in the Signal K app Log Viewer, I see this output for the same time period:

Started signalk.service.
The installed version of node (v20.5.1) is different than the recommended version (22). See https://github.com/SignalK/signalk-serve...ng-Node.js for more information how to upgrade.
2026-01-05T18:32:58.962Z signalk-logviewer Plugin started
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
*** WARNING *** The program 'node' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
*** WARNING *** The program 'node' called 'DNSServiceRegister()' which is not supported (or only supported partially) in the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/blog/projects/avahi-compat.html>
signalk-server running at 0.0.0.0:[object Object]
Redirect server running on port [object Object]
unable to check for new server version: TypeError: fetch failed
5 Jan 10:32:59 - [info]
Welcome to Node-RED
===================
5 Jan 10:32:59 - [info] Node-RED version: v4.1.2
5 Jan 10:32:59 - [info] Node.js version: v20.5.1
5 Jan 10:32:59 - [info] Linux 6.12.47+rpt-rpi-2712 arm64 LE
5 Jan 10:32:59 - [info] Loading palette nodes
pi : PWD=/home/pi/.signalk ; USER=root ; COMMAND=/usr/bin/date
pi : PWD=/home/pi/.signalk ; USER=root ; COMMAND=/usr/bin/date --iso-8601 -u -s 2026-01-05T19:06:01.000Z
pam_unix(sudoession): session opened for user root(uid=0) by (uid=1000)
pam_unix(sudoession): session opened for user root(uid=0) by (uid=1000)
pam_unix(sudoession): session closed for user root
pam_unix(sudoession): session closed for user root

[PaddyB]

That ip address https://192.168.0.145:3443/admin/#/dashboard - are you using a mobile phone as a hotspot with the Pi connected to that? I've had problems before with android blocking ssh and doing weird things, does it work if you connect to the Pi hotspot on 10.42.0.1?

[rytz]

Hi PaddyB, thanks for your reply. This is starting to make more sense.

While I have used my phone's personal hotspot at times, at the moment it's connected and I'm testing on my home network which uses a TP-Link Router and the issue is happening there. I haven't ever used the Pi hotspot feature. Is this the intended default way to network OpenPlotter? I suppose that makes sense as it doesn’t require other hardware; just the Pi. I hadn't considered how to network in an actual boat yet and figured I would use some sort of router, but if the Pi access point (AP) is the intended way, I'll just do that.

I'm using the Touchscreen Raspi image. Reading the specs on the different versions, I see that the Touchscreen image is not configured by default for the Access Point so will have to enable it. 

I wonder why it is not enabled by default? Is this for the user to do or are they supposed to use another method to connect devices?

Will play with that functionality and report back. Thanks for the suggestion.

[rytz]

UPDATE: I turned on the AP and after switching to the AP from my Windows laptop (where I work usually, run VNC to the Pi, and access Signal K from the browser) and turning off the home Wi-Fi connection the Pi didn’t have Internet access anymore, which doesn’t work. Connecting back to the home Wi-Fi network and running the AP simultaneously doesn’t make sense, either, but that’s what I’m doing at the moment. It seems I’m still just kind of waiting for the issue to occur again with no real improvement in how to identify it when it does.

Where is Internet access supposed to come from out on the water? For reference, although I mentioned an Android phone running OpenCPN my only cell-based network access is through my iPhone with T-Mobile Hotspot, which I would plan to use on the water when the time comes. How would that work with the AP setup? It seemed more logical to me to just use the phone as the router, which is what I was trying to simulate with the home network, if that makes sense. I’m not sure I understand how using it over the TP-Link router network should cause the main unresponsive-type errors I’ve described above.

As I am not sure I know what I’m looking for exactly I have tried to pose my question to be more of a general inquiry as to how to shore up one’s logging efforts. I pasted my Log Viewer app and Server Logs outputs above with hopes of determining further known courses of action to identify issues. Does anyone have any suggestions for this or can at least confirm the existing options for maximizing output?

As I mentioned before, I also have Debug mode enabled as outlined in the Bug Reports thread, but am not sure what output that produces. Can someone please advise? The documentation refers to a ‘log file;’ what or where that is is vague.

[PaddyB]

Where is Internet access supposed to come from out on the water? 

It doesn't 
IMHO the nav computer for the boat is far too important to be online at sea, even if I had starlink or something for web access on passage. Though saying that the Pi can be set to both create a network and join another network at the same time, not really a good idea as it can cause problems though the Pi 5 seems pretty good. I use a usb/wifi dongle so the 10.42.0.1 net work is created by the Pi and it can log on to another network as well. Then the Pi will let anything connected to 10.42.0.1 can access the web as well with the data being sent through the Pi.

[rytz]

Thanks, PaddyB. That makes sense. I guess based on your initial reply I thought perhaps the issue I was experiencing was somehow caused by problematic network traffic, but it doesn't seem likely.

Since last night the issue occurred again, and this time I had the display connected. The OpenPlotter desktop background image showed but icons were broken and as soon as I pressed a key the screen went blank with the cursor at top left. Seemed like I/O error behavior if I've ever seen it. I didn't want to believe it due to the brand new (and relatively expensive) components in the Pi, but perhaps the SSD is bad. I will run a full diagnostic and report back. Thanks again.

---

I uninstalled the Fanxiang 2TB NVME SSD and reinstalled the 128GB micro SD card I used before I cloned it to the NVME with all my basic configuration still intact. Running that with MacArthur HAT and all same setup as before. Will see if the behavior persists.

[tkurki]

Could not handle admin ui root request’ error means that the server is unable to read the admin ui index.html file from the disk. Either admin ui webapp is completely missing or something else is making that read operation fail.

[rytz]

Thanks for the confirmation from the technical side, tkurki. I/O error still seems like the main suspect, then.

Since my last post I decided to strip everything back down and start from scratch to eliminate as many variables as possible. I've got a 16GB micro SD flashed with the bare Touchscreen image again and reconfigured (twice, after mistakenly enabling SSL on port 3443--couldn't get back in!) all the settings I had before, sparing all OpenPlotter plugins I had, and will just run that for as long as I can and hope it continues to run without issue. I'll report back when I have some good conclusions.