All Apps Disappeared from GUI After Middleware Restart - TrueNAS 25.04.2.4

Problem Summary

All 45 installed applications disappeared from the TrueNAS GUI after running sudo systemctl restart middlewared while apps were updating. The apps continue to run perfectly in the background via Docker, but the GUI shows “No Applications Installed” and I’ve lost all management capabilities.

System Information

  • TrueNAS Version: 25.04.2.4 (Fangtooth)
  • Number of Apps Affected: 45 apps (Nextcloud, Vaultwarden, N8N, Jellyfin, etc.)
  • Pool: Data/
  • Platform: Intel

What Happened

  1. Was updating multiple apps through the GUI
  2. Updates got stuck at 60% for extended period
  3. Ran sudo systemctl restart middlewared to unstick the process
  4. After restart, GUI shows zero apps installed
  5. All Docker containers still running and accessible
  6. midclt call app.query returns empty array []

Current Status

:white_check_mark: Working:

  • All 45 Docker containers running (docker ps shows all healthy)
  • All services accessible at their configured ports
  • All data intact in /mnt/.ix-apps/app_configs/
  • All apps are on latest versions

:x: Broken:

  • TrueNAS GUI shows “No Applications Installed”
  • Cannot manage, update, or configure apps through GUI
  • Middleware completely ignores existing apps

Troubleshooting Already Performed

File System Check

ls /mnt/.ix-apps/
# Found:
- collective_metadata.yaml (89KB - contains all app metadata)
- collective_config.yaml (227KB - contains all app configs)
- user_config.yaml (232KB - contains user settings)
- metadata.yaml (created manually)
- app_configs/ (all 45 apps present with metadata)

Middleware Verification

midclt call app.query
# Returns: []

midclt call docker.config
# Returns: {"enable_image_updates": true, "dataset": "Data/ix-apps", ...}

sudo journalctl -u middlewared --since "5 minutes ago"
# No errors related to apps

Recovery Attempts

  1. :white_check_mark: Restored collective_metadata.yaml from backup (Sept 25, 2025)
  2. :white_check_mark: Restored collective_config.yaml from backup
  3. :white_check_mark: Created new metadata.yaml with all 45 apps listed
  4. :white_check_mark: Restarted middlewared multiple times
  5. :white_check_mark: Full system reboot
  6. :white_check_mark: Verified all YAML files are valid and readable
  7. :white_check_mark: Confirmed Docker service is running
  8. :x: Nothing makes apps reappear in GUI

File Contents Verified

sudo head -30 /mnt/.ix-apps/collective_metadata.yaml
# Shows: adguard-home, nextcloud10, and all other apps with full metadata

sudo grep "nextcloud10" /mnt/.ix-apps/collective_metadata.yaml
# Returns: nextcloud10:

The collective YAML files contain complete, valid data for all apps, but middleware refuses to read them.

Technical Observations

  • The app_app database table doesn’t exist (KeyError when querying)
  • TrueNAS 25.04 appears to be fully file-based (no SQL database for apps)
  • Middleware should be reading from collective_metadata.yaml but isn’t
  • No cached state files found that could be cleared
  • Docker containers have all correct labels and configurations

Questions

  1. Is there a middleware command to force re-scan of collective_metadata.yaml?
  2. Is there an internal cache or state file that needs to be cleared?
  3. Has anyone else experienced this after restarting middleware during app operations?
  4. Is there a recovery tool/script to rebuild app tracking from existing configs?

Request for Help

This appears to be a critical bug where middleware restart during app operations permanently corrupts app tracking, even though all underlying data remains intact. I need either:

  • A way to force middleware to recognize existing apps from the YAML files
  • An official recovery procedure from iXsystems
  • Confirmation this is a known bug with an upcoming fix

I cannot reinstall 45 apps manually - this would take hours and risk data loss. The apps work perfectly; I just need GUI management back.

Has anyone successfully recovered from this situation? Any official guidance from the TrueNAS team would be greatly appreciated.

Did you unset the pool and reset it?


I just wrote a few paragraphs discussing my issues and problems with the apps UI but it came off super immature.

I’m reading everything you wrote, and I will be trying some of the things you mentioned to fix my apps ui. I find it strange that there is a level of complexity where diagnostics guides can’t be provided from IX for the app web UI at this point in my experience with TrueNAS. I’ve only been using it for just over a year, but had “close calls” before with my apps seemly suddenly unavailable, and then finally 1.5 weeks ago I hit a point of no return (or so it seems).

Admitingly I still want to keep using Apps UI over apps like dockge, but I find it super discouraging when all my interactions with IX staff hasn’t left me feeling any sense of happiness, feeling heard, or any optimism for the future of allowing TrueNAS to natively secure my docker applications on the back-end.

Wishing you luck with your troubleshooting. Again, I’ll be following this post hopefully to see others help you find a resolution.

FIXED!?
I stopped one of my apps (whoogle) through console and installed the app through truenas ui again.
I got error FILE EXISTS (/mnt/.ix-apps/app_configs/whoogle/versions/1.2.13).
I checked in console for file and didn’t find it.
I installed through ui again.

→ Whoogle installed and ALL Apps in ui again (updates & restarting works so far)

1 Like

Interesting!

I wonder if it’s anything simple like that with mine. I changed a few files but they all followed similar syntax.

I agree with some of your points in “Questions” though. Having a middleware command to re-scan/re-sync/or even have a DB cleanup style tool would be great.

I keep wanting to go ahead with backing up and starting from scratch (with the app mounts as backups) but paranoid of leaving something ungracefully behind.

Your post gives me some hope though! Good work.:slightly_smiling_face:

only took me just less than 2 weeks to get my apps ui working. just had to access datasets before it had a chance to error out and revert the following snapshot

Maybe a few other steps in-between but if you run into apps UI not loading ever, saying something about portalsURI validation errors might be coincidence, but this might help as well.

I also forced stopped all dockers (ie. docker stop $(docker ps -aq) under root user) and removed some containers entirely that would persistently start on bootup.