Security Check Fails with 401 Error After Consecutive Updates (30.0.0 → 30.0.1 → 30.0.2)

[Diogo-Rego]

Steps to Reproduce:

1. Deploy Nextcloud using Helm chart (version: X.X.X).
2. Update Nextcloud from version 30.0.0 to 30.0.1 using Helm:

helm upgrade my-nextcloud nextcloud/nextcloud --set image.tag=30.0.1

• System functions normally, no issues observed.

3. Immediately update from 30.0.1 to 30.0.2 using Helm:

helm upgrade my-nextcloud nextcloud/nextcloud --set image.tag=30.0.2

• The update completes successfully, and the system appears functional.

4. Access Settings > Administration > Overview for the Security & Setup Warnings check.

Expected Behavior:

• The Security Check should display no issues if the system is correctly configured.

Actual Behavior:

• The Security Check fails, and the logs show a 401 Unauthorized error related to remote.php.

Logs: From nextcloud.log:

{
  "reqId": "XXXX",
  "level": 3,
  "time": "YYYY-MM-DDTHH:MM:SSZ",
  "remoteAddr": "IP_ADDRESS",
  "user": "--",
  "app": "PHP",
  "method": "GET",
  "url": "/remote.php",
  "message": "401 Unauthorized"
}

Notes:

• If I skip the intermediate step and directly update from 30.0.0 to 30.0.2, the problem does not occur.

• Running occ maintenance:repair or clearing the cache after the first update does not seem to prevent this issue.

• This issue seems related to intermediate migrations or state inconsistencies during back-to-back updates.

Environment:

• Nextcloud Version: 30.0.0 → 30.0.1 → 30.0.2
• Deployment: Helm chart on Kubernetes
• Database: PostgreSQL
• Cache: Redis
• PHP Version: X.X
• Web Server: NGINX
• Authentication: (e.g., local, SAML, LDAP, etc.)

Troubleshooting Steps Taken:

1. Restarted all related services (Nextcloud, Redis, PostgreSQL).
2. Verified permissions for remote.php.

Additional Information:

• This issue seems related to token or session management.

• Happy to provide more logs or test specific fixes.

[provokateurin]

This sounds like it is not related to the Helm chart itself but rather a bug in server.

[Diogo-Rego]

This sounds like it is not related to the Helm chart itself but rather a bug in server.

The problem seems to be with migrations to PostgreSQL.