AIO: Nextcloud becomes unresponsive while Mail app logs repeated `kitinerary-extractor: not found`

[vawaver]

Steps to reproduce

Environment

• Nextcloud AIO: 11.9.0
• Nextcloud version: 31.0.9
• Nextcloud Mail app: 5.5.6
• Deployment type: Official Nextcloud AIO Docker stack

---

Description

Nextcloud suddenly became completely unresponsive — the web UI stopped loading and PHP stopped responding.
The nextcloud-aio-nextcloud container logs were filled with repeated errors like:

sh: /var/www/html/custom_apps/mail/vendor/nextcloud/kitinerary-bin/src/../bin/kitinerary-extractor: not found
sh: flatpak: not found
sh: kitinerary-extractor: not found

Restarting only the nextcloud-aio-nextcloud container immediately restored full functionality.
The Mail app remained enabled during the entire incident — there were no manual changes or configuration edits.

occ status output before/after restart:

- installed: true
- version: 31.0.9.1
- maintenance: false
- needsDbUpgrade: false

---

Steps to Reproduce (as observed)

1. Run Nextcloud AIO 11.9.0 with Nextcloud 31.0.9 and Mail app 5.5.6.
2. After some time (normal operation, not during update), the container nextcloud-aio-nextcloud begins logging kitinerary-extractor: not found and flatpak: not found errors repeatedly.
3. The Nextcloud UI becomes unreachable (no response from PHP backend).
4. Restarting the container nextcloud-aio-nextcloud resolves the issue temporarily.

---

Expected Behavior

If the kitinerary-extractor binary (KDE Itinerary parser) is missing inside AIO, the Mail app should gracefully skip itinerary extraction without affecting overall system stability.

---

Actual Behavior

Missing kitinerary-extractor causes repeated execution attempts in Mail, filling logs and eventually freezing PHP inside the nextcloud-aio-nextcloud container, making the entire instance unresponsive until manually restarted.

---

Workaround

Manually restarting the container nextcloud-aio-nextcloud restores functionality.
No configuration or app changes were made to recover the instance.

---

Notes

This appears to be an interaction between the Mail app and the AIO environment.
The AIO containers do not include kitinerary-extractor or flatpak, and the Mail app does not degrade gracefully when these binaries are missing.

Expected behavior

Expected Behavior

If the kitinerary-extractor binary (KDE Itinerary parser) is missing inside AIO, the Mail app should gracefully skip itinerary extraction without affecting overall system stability.

Actual behavior

Actual Behavior

Missing kitinerary-extractor causes repeated execution attempts in Mail, filling logs and eventually freezing PHP inside the nextcloud-aio-nextcloud container, making the entire instance unresponsive until manually restarted.

Mail app version

No response

Nextcloud version

No response

Mailserver or service

No response

Operating system

No response

PHP engine version

None

Nextcloud memory caching

No response

Web server

None

Database

None

Additional info

No response

[kesselb]

Thanks for the issue 👍

sh: flatpak: not found
sh: kitinerary-extractor: not found

That error was reported some time ago without a mention of some container becoming unresponsive.

#6000
#7603
#7899
#8322

How do you know the "unresponsiveness" is caused by that log message?

[vawaver]

The issue is that when those kitinerary-extractor errors start flooding the logs, the entire Nextcloud instance becomes completely unresponsive, not just the Mail app.

• The web UI stops working entirely — either a blank screen or it redirects to the login page, but after entering username and password, it just hangs and never reaches the TOTP verification page.
• None of the other apps (Files, Talk, Calendar, etc.) can be loaded.
• Both the Nextcloud Desktop Client and Nextcloud Talk Desktop lose connection and fail to reconnect.
• In Portainer, all containers are shown as running and healthy (no container crash or restart).

The error messages are specifically coming from the container nextcloud-aio-nextcloud.
If I remember correctly, there were no related errors in the nextcloud-aio-apache container logs — everything there looked normal.

Restarting only the nextcloud-aio-nextcloud container immediately restores the full functionality of the entire instance.
That’s why it strongly appears that the unresponsiveness is directly tied to this error loop inside the nextcloud-aio-nextcloud container.

[vawaver]

Update to v5.5.7 does not solve the issue.