Describe the bug
I updated my etherpad instance from 2.6.1 to 3.3.3 and everything worked out of the box, only the readonly filesystem is causing issues.
To Reproduce
Deploy following manifest:
apiVersion: v1
data:
ADMIN_PASSWORD: nonEmpty
DB_FILENAME: var/etherpad.sq3
DB_TYPE: sqlite
DEFAULT_PAD_TEXT: ' '
DISABLE_IP_LOGGING: "true"
NODE_ENV: production
# changed port to > 1024 to prevent running with additional capabilities
PORT: "9001"
PRIVACY_PLUGIN_CATALOG: "false"
PRIVACY_UPDATE_CHECK: "false"
TRUST_PROXY: "true"
UPDATES_TIER: "off"
kind: ConfigMap
metadata:
annotations:
meta.helm.sh/release-name: jitsi
meta.helm.sh/release-namespace: jitsi
creationTimestamp: "2026-07-23T21:38:41Z"
labels:
app.kubernetes.io/component: etherpad
app.kubernetes.io/instance: jitsi
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: jitsi-meet
app.kubernetes.io/version: stable-11031
helm.sh/chart: jitsi-meet-2.22.2
helm.toolkit.fluxcd.io/name: jitsi
helm.toolkit.fluxcd.io/namespace: jitsi
name: jitsi-jitsi-meet-etherpad
namespace: jitsi
---
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
deployment.kubernetes.io/revision: "13"
meta.helm.sh/release-name: jitsi
meta.helm.sh/release-namespace: jitsi
creationTimestamp: "2026-07-23T21:38:41Z"
generation: 13
labels:
app.kubernetes.io/component: etherpad
app.kubernetes.io/instance: jitsi
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: jitsi-meet
app.kubernetes.io/version: stable-11031
helm.sh/chart: jitsi-meet-2.22.2
helm.toolkit.fluxcd.io/name: jitsi
helm.toolkit.fluxcd.io/namespace: jitsi
name: jitsi-jitsi-meet-etherpad
namespace: jitsi
resourceVersion: "11204879"
uid: 01876c30-8453-433a-8978-6b65bfe1da9b
spec:
progressDeadlineSeconds: 600
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
app.kubernetes.io/component: etherpad
app.kubernetes.io/instance: jitsi
app.kubernetes.io/name: jitsi-meet
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate
template:
metadata:
annotations:
checksum/config: 34dd7030c68a6f22361d17e07521f7431ec66d30524ab0725060fa8655283dcd
labels:
app.kubernetes.io/component: etherpad
app.kubernetes.io/instance: jitsi
app.kubernetes.io/name: jitsi-meet
spec:
automountServiceAccountToken: false
containers:
- envFrom:
- configMapRef:
name: jitsi-jitsi-meet-etherpad
image: etherpad/etherpad:3.3.3
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /
port: 9001
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
name: jitsi-meet
ports:
- containerPort: 9001
name: http
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /
port: 9001
scheme: HTTP
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 1
resources: {}
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 5001
seccompProfile:
type: RuntimeDefault
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
volumeMounts:
- mountPath: /tmp
name: tmp
- mountPath: /opt/etherpad-lite/var
name: data
- mountPath: /opt/etherpad-lite/src/plugin_packages
name: plugins
dnsPolicy: ClusterFirst
restartPolicy: Always
schedulerName: default-scheduler
securityContext: {}
serviceAccount: jitsi-jitsi-meet
serviceAccountName: jitsi-jitsi-meet
terminationGracePeriodSeconds: 30
volumes:
- emptyDir: {}
name: tmp
- emptyDir: {}
name: data
- emptyDir: {}
name: plugins
Expected behavior
Etherpad is running in readOnlyFilesystem: true
Screenshots
If applicable, add screenshots to help explain your problem.
Server (please complete the following information):
- Etherpad version: 3.3.3 as docker image
Additional context
When running with readOnlyRootfilesystem: false the container is able to start. In my point of view the plugin migration does somewhere need additional write permissions.
Describe the bug
I updated my etherpad instance from 2.6.1 to 3.3.3 and everything worked out of the box, only the readonly filesystem is causing issues.
To Reproduce
Deploy following manifest:
Expected behavior
Etherpad is running in readOnlyFilesystem: true
Screenshots
If applicable, add screenshots to help explain your problem.
Server (please complete the following information):
Additional context
When running with readOnlyRootfilesystem: false the container is able to start. In my point of view the plugin migration does somewhere need additional write permissions.