Environment:

• OneDev: 16.3.4
• Helm chart: 16.3.4
• Kubernetes workspace provisioner
• Kubernetes helper: 4.1.8
• Workspace image: 1dev/codex
• Workspace Run As: 1001:1001
• OneDev uses custom trusted certificates from /opt/onedev/conf/trust-certs

Problem:

Kubernetes workspaces fail to start when custom trusted certificates are configured in OneDev.

This currently also prevents AI pull request reviews from running, as recent OneDev versions create a workspace to perform the review.

The repository itself is cloned successfully. However, the workspace initialization fails while attempting to change the ownership of /onedev-workspace:

Downloading user data 'codex'...
chown: changing ownership of '/onedev-workspace/trust-certs': Read-only file system
chown: changing ownership of '/onedev-workspace/trust-certs/..data': Read-only file system
chown: changing ownership of '/onedev-workspace/trust-certs/1.pem': Read-only file system
io.onedev.commons.utils.ExplicitException: Command execution failed
(command: chown -R 1001:1001 /onedev-workspace, exit code: 1)
    at io.onedev.k8shelper.KubernetesHelper.changeOwner(KubernetesHelper.java:458)
    at io.onedev.k8shelper.WorkspaceHelper.init(WorkspaceHelper.java:194)
    at io.onedev.k8shelper.WorkspaceInit.main(WorkspaceInit.java:17)

The init container exits with code 1, after which the workspace is stopped.

Suspected cause:

KubernetesProvisioner creates a ConfigMap containing OneDev's trusted certificates and mounts it at:

/onedev-workspace/trust-certs

Kubernetes ConfigMap volumes are read-only. The WorkspaceInit container subsequently runs:

chown -R <runAs> /onedev-workspace

The recursive ownership change enters the nested ConfigMap mount and fails, even though the actual workspace PVC is writable.

This appears to affect Kubernetes workspaces using a non-root Run As value whenever custom trusted certificates are configured.

Could you please have a look and confirm whether this is a bug or whether there is a recommended workaround?

Thank you very much!