Als elke app van het ZimaOS-startscherm verdwijnt, maar de server en gegevens nog bereikbaar zijn, ga er dan niet van uit dat de NAS defect is of dat je apps zijn verwijderd. Controleer eerst de exacte ZimaOS-versie, of de Docker-containers nog bestaan en of het probleem alleen een regressie in de frontend of het dashboard is.
De oorspronkelijke situatie is een goed voorbeeld: op ZimaOS 1.6.1 zag de gebruiker in meerdere browsers geen apps en vreesde die voor een aanstaande systeemstoring. Na een upgrade naar 1.6.2 kwamen de apps terug. Dat is door een gebruiker bevestigde herstelactie, maar in de thread staat geen verklaring van IceWhale waaruit blijkt dat alle gevallen van ontbrekende apps het gevolg waren van een universele bug in 1.6.1.
Stap 1: Controleer of de apps echt weg zijn
Open de terminal en controleer Docker:
docker ps -aAls je containers nog worden weergegeven, bestaan de appdefinities en gegevens waarschijnlijk nog, ook als het startscherm leeg is.
Als Docker zelf een foutmelding geeft, ligt het probleem dieper dan het dashboard en moet het worden onderzocht als een service- of opslagprobleem.
Stap 2: Controleer de exacte ZimaOS-versie
De oorspronkelijke gebruiker gebruikte versie 1.6.1 en meldde dat het bijwerken naar 1.6.2 de apppictogrammen herstelde. De officiële releaseopmerkingen voor ZimaOS 1.6.2 beschrijven bredere stabiliteits- en opslagverbeteringen, maar documenteren het specifieke probleem van de gebruiker met ontbrekende apps niet.
Gebruik je al een nieuwere stabiele release, downgrade dan niet naar 1.6.2 alleen omdat die versie één historisch geval heeft opgelost.
Stap 3: Test het dashboard in een schone browsersessie
Gebruik een privé- of incognitovenster en voer een harde vernieuwingsactie uit. Schakel tijdens het testen agressieve inhoudsblokkers of scriptfilters uit voor het lokale ZimaOS-adres.
De oorspronkelijke gebruiker had Brave, Firefox en Chrome al geprobeerd, waardoor een eenvoudig cacheprobleem in één browser minder waarschijnlijk was. Toch blijft deze controle nuttig voor huidige gevallen.
Stap 4: Test via het IP-adres en de hostnaam
Open zowel het directe LAN-IP-adres als je gebruikelijke lokale hostnaam. Als het appdashboard via de ene route wel wordt geladen en via de andere niet, onderzoek dan DNS, gecachte frontend-assets of browseropslag die aan de specifieke origin is gekoppeld.
Als beide een leeg startscherm tonen terwijl de Docker-containers correct werken, richt je dan op de frontend- of backendservice van ZimaOS die de applijst beheert, in plaats van Docker-apps opnieuw te installeren.
Stap 5: Controleer de opslag voordat je herhaaldelijk opnieuw opstart
De oorspronkelijke gebruiker meldde ook dat schijven soms verdwenen en dat dagelijkse herstarts nodig waren. Dat is een afzonderlijk symptoom met hoge prioriteit, omdat ontbrekende AppData-opslag ervoor kan zorgen dat toepassingen niet worden weergegeven of gestart.
Controleer Instellingen → Opslag en bevestig dat de AppData-locatie is gekoppeld. De actuele handleiding voor opslagconfiguratie van ZimaOS legt de huidige indicatoren voor schijf- en arraystatus uit.
Installeer apps pas opnieuw nadat je weet dat hun gegevens veilig zijn
Als de containers en AppData nog bestaan, kan opnieuw installeren via de App Store dubbele paden, nieuwe volumes of verwarring veroorzaken over welke gegevens bij welke instantie horen.
De handleiding voor het oplossen van problemen met Docker-apps helpt onderscheid te maken tussen een verdwenen gebruikersinterface en daadwerkelijk verloren containers.
Zo onderscheid je een UI-storing van een appstoring
| Symptoom | Waarschijnlijke laag |
|---|---|
| Leeg startscherm, containers aanwezig en actief | Dashboard, applijst-UI of backendmetagegevens |
| Containers aanwezig maar gestopt | Docker- of appconfiguratie, of een afhankelijkheidsprobleem |
| Containers ontbreken maar AppData is aanwezig | Herstelpad voor appmetagegevens of herinstallatie |
| AppData-opslag ontbreekt | Probleem met opslagkoppeling, rechten of schijf |
| Dashboard en terminal zijn beide niet beschikbaar | Systeem-, netwerk- of servicestoring |
Wanneer je moet bijwerken en wanneer je logboeken moet verzamelen
Als er een nieuwere stabiele ZimaOS-release beschikbaar is en je back-up actueel is, is bijwerken redelijk—vooral als het probleem direct na een eerdere update begon. Maar als de opslag verslechterd is of de systeemschijf defect raakt, bescherm of herstel dan eerst de gegevenslaag.
Als het probleem in de nieuwste stabiele release blijft bestaan, verzamel dan consolefouten uit de browser, docker ps -a, de huidige opslagstatus, de ZimaOS-versie en relevante systeem- en app-servicelogboeken voor de ondersteuning.
Veelgestelde vragen
Heeft ZimaOS 1.6.2 ontbrekende apppictogrammen opgelost?
De versie loste het geval van de oorspronkelijke gebruiker op ZimaOS 1.6.1 op. De thread bewijst niet dat elk probleem met ontbrekende apps dezelfde oorzaak had.
Zijn mijn apps verwijderd als het startscherm leeg is?
Niet noodzakelijk. Controleer docker ps -a en de AppData-opslag voordat je iets opnieuw installeert.
Kan de browsercache alle ZimaOS-apps verbergen?
Een verouderde frontend kan UI-problemen veroorzaken, dus een harde vernieuwingsactie of een privévenster is het testen waard. Als elke schone browser hetzelfde gedrag vertoont, onderzoek dan vervolgens de serverkant.
Moet ik back-upschijven kopen voordat ik bijwerk?
Back-ups bijhouden is altijd verstandig, maar een leeg dashboard bewijst op zichzelf geen aanstaand gegevensverlies. Controleer eerst de systeem- en opslagstatus.
