Problem
After upgrading to OX Connector 4.0.0, the container may enter a restart loop and provisioning to Open-Xchange stops. New users, functional accounts, or permission changes are no longer synchronized.
Depending on the upgrade state, the following errors may occur:
ValidationError: OXConsumerSettings
log_level
input_value='None'
ValidationError: MessageHandlerSettings
max_acknowledgement_retries
Field required
sqlite3.IntegrityError:
NOT NULL constraint failed: tasks.attrs
Investigation
Check the container status and logs:
docker ps -a
univention-app logs ox-connector
Inspect the App Center log for failed configuration attempts:
grep -E 'Cannot write settings|Failed to configure' /var/log/univention/appcenter.log
A failed upgrade may leave required application settings missing or cause database compatibility issues.
Check the existing SQLite schema:
python3 - <<'PY'
import sqlite3
db = "/var/lib/univention-appcenter/apps/ox-connector/data/ox-connector.db"
con = sqlite3.connect(f"file:{db}?mode=ro", uri=True)
for table in ("tasks", "morgue", "old"):
attrs = next(
row for row in con.execute(f'PRAGMA table_info("{table}")')
if row[1] == "attrs"
)
print(table, "attrs NOT NULL:", bool(attrs[3]))
PY
OX Connector 4.0.0 requires tasks.attrs and morgue.attrs to allow NULL values for delete events.
Root Cause
OX Connector 4.0.0 introduced major architectural changes, including migration to the Nubus Provisioning Service and a new container image.
In the investigated installation, an interrupted upgrade resulted in:
- Missing application settings.
- An incomplete SQLite schema migration.
- Legacy cached
oxContextvalues stored as strings instead of integers.
The original OX Connector 4.0.0 image also contained a migration compatibility issue that could incorrectly interpret unchanged OX contexts as context changes and trigger destructive user recreation.
Univention subsequently replaced and re-released the 4.0.0 image under the same version tag.
Solution
The recommended recovery procedure for installations already updated to the original 4.0.0 image is to download the corrected image and recreate the container.
Before proceeding, ensure that a backup of the persistent OX Connector data exists.
Run on the server hosting OX Connector:
docker pull docker.software-univention.de/ox-connector:4.0.0
univention-app reinitialize ox-connector
The first command downloads the currently published image. The second recreates the application container using that image and the existing persistent application data.
Verify the container state:
docker ps -a
Check provisioning health:
univention-ox-connector-task-management summarize-tasks
univention-ox-connector-task-management search-morgue
The connector should remain running without restart loops, and provisioning tasks should be processed successfully.
If the connector still fails because of missing settings or SQLite schema constraints, the persistent application state may require additional recovery. These database changes should be performed only after examining the existing schema and creating a backup. Reinitializing the container alone does not necessarily repair an already inconsistent database.
Do not delete the connector database or trigger a full reprovisioning as a general recovery measure.
Related information:
OX Connector 4.x documentation:
https://docs.software-univention.de/ox-connector/4.x/en/troubleshooting/index.html
Known oxContext migration compatibility issue: