Harbor App (Appimage) cannot load config

[FrantaNautilus]

After making a clean install of harbor CLI (harbor doctor shows everything OK), I tried the Harbor App via AppImage. No AppImage wrapper was used, only chmod +x HarborApp.AppImage and ./HarborApp.AppImage.
The problem is only the Profiles tab which outputs an error "Unexpected error loading configuration".

Other tabs are unaffected.

[av]

Thank you so much for another report!

Unfortunately I can't reproduce it right away, so we'll have to debug

Just released v0.2.12 comes with a couple of things that should help:

• harbor doctor now prints location of the Harbor Home, it should be present in the App in the "CLI" page, could you please check that the value there matches what you see when running the harbor doctor in the terminal?
• Fixed one edge-case related to a deletion of a currently selected config profile. The error state looks slightly different compared to your screenshot, but worth trying it out with the new app build

Other than that - I have a suspicion that it might be related to either:

• AppImage sandboxing which isn't kicking in on my system and is available by default on yours (Fedora SilverBlue, right?)
• AppImage not bundling correct dependencies (unlikely, but not impossible)

[FrantaNautilus]

As before thank you for quick update of harbor, however the problem persists. I followed the troubleshooting you have suggested and here are the results.

Harbor App doctor (the values match between App and CLI):
✔ Docker is installed and running
✔ Docker Compose (v2) is installed
✔ Harbor home: /var/home/user/.harbor
✔ Default profile exists and is readable
✔ Current profile (.env) exists and is readable
✔ CLI is linked
✔ NVIDIA Container Toolkit is installed

CLI:
14:57:09 [INFO] ✔ Docker is installed and running
14:57:09 [INFO] ✔ Docker Compose (v2) is installed
14:57:09 [INFO] ✔ Harbor home: /var/home/user/.harbor
14:57:09 [INFO] ✔ Default profile exists and is readable
14:57:09 [INFO] ✔ Current profile (.env) exists and is readable
14:57:09 [INFO] ✔ CLI is linked
14:57:09 [INFO] ✔ NVIDIA Container Toolkit is installed

I tried to disable sandboxing for the AppImage by running it with --no-sandbox flag, however the problem persists (the output remains the same).

I have also tried to make clean manual install instead of automated. And the error remains.

What I found are some fixed issues concerning Fedora Silverblue and broken support of AppImage. For example fedora-silverblue/issue-tracker#589. Yet none of the problems reported there seem to be connected to this one. I plan to upgrade to Fedora Silverblue 41 soon (probably next weekend), so I can test if there is anything different.

Also, can I ask if you have any plans for Flatpak release? Flatpak in my experience has fewer (user side) problems than AppImage.

[av]

Yeah, nothing in these looks suspicious in any way. The --no-sandbox seems to be related to the Electron apps (Harbor runs with Tauri). Granted the homedir location, could you please try running it with: --filesystem=/var? Very thin chance, but still

I'm certain that this happens because of some sort of discrepancy in the FS access permissions between the systems with a very short possible fix. As another attempt - could you please try running it via AppImage launcher?

any plans for Flatpak release?

Unfortunately in Harbor's case, the Flatpak would be just a repackaged .deb, I'm not 100% it'll work on Silverblue (just learned about immutable FS), It looks like you won't be able to use the provided rpm due to exactly the same reason

[av]

I've added a "guess" fix to https://github.com/av/harbor/releases/tag/v0.2.14 with an explicit permission to read/write to the User's home folder (previously was under the wildcard). Also a thin chance that it fixes the problem for you, but please try running the AppImage from that release

[FrantaNautilus]

Thank you for incredibly fast update, I updated CLI and the App. Nevertheless, the problem remains the same in version 0.2.14 with or without --filesystem=/var flag.
I noticed that the button create profile is clickable despite the error. The profile creation dialog opens and upon clicking create profile the screen flashes and dialog closes, simultaneously the following error is produced in command line:

** (harbor-app:364900): WARNING **: 19:10:21.768: atk-bridge: get_device_events_reply: unknown signature

Hopefully I will be able to install the rpm version on my test PC tomorrow (running the same Fedora Silverblue 40, installation via layering of the package).

[av]

No worries!

I'll try to find some time to test the AppImage in a VM during my next chunk of Harbor time (next weekend or a weekend after that)

Thanks for sticking it out through the early versions

[FrantaNautilus]

Sorry for taking long with a reply, I am still having issues with upgrading to Fedora 41 (Nvidia drivers), so for now I tried to install the Harbor App into Fedora toolbox (which is should have access to the system as if I installed on non-immutable Fedora). The App is installed without any errors, but the problem remains the same as with the AppImage. Now the only thing that these different installations have in common is that home directory is under /var and security policy of Fedora.

[av]

I was working on a somewhat related feature (that'll eventually also let me test the app in the Fedora easier) and found out a possible culprit.

I think that the desktop entry in Fedore will run in a custom shell without the $PATH modification added by Harbor. Theoretically, when starting the App from a terminal directly, it should inherit the correct env and have access to Harbor's executable.

So, could you please try launching the app from the terminal instead of the desktop entry and let me know if it makes the app functioning?

# App's binary is named "harbor-app" and should be made available
# on the host during install
which harbor-app
# Should be something like: /usr/bin/harbor-app

# If not found - look into the .desktop entry for the app:
cat /usr/share/applications/Harbor.desktop 

# Launch the app binary directly:
harbor-app

I'm currently trying to find any workarounds, but still curious to know if this was the reason in your instance.

Thanks!

[FrantaNautilus]

Thank you for coming back to my issue. I am sorry I did not reply immediately, however I am still figuring out how to properly install RPM package on the immutable Fedora Silverblue (without breaking anything else). I updated to the latest version of harbor (CLI and App Appimage) and the issue persists. As for the debugging steps you suggest for the RPM, I tried to install RPM through Distrobox which shares the system configuration partially, yet it cannot detect Docker. I will have to layer the RPM directly.

[av]

Absolutely no worries!

I'm hoping to get my hands on testing this next weekend. Recent Harbor release included webtop service with the Harbor App pre-installed, could be used as a workaround until we get it to work natively