gitea/helm-gitea
Fork 169
Code Issues 54 Pull Requests 11 Actions Releases 103 Activity

mkdir /data/attachments: permission denied #135

New Issue
Closed
opened 2021-03-29 15:54:17 +00:00 by Dunky13 · 16 comments
Dunky13 commented 2021-03-29 15:54:17 +00:00
Contributor
Copy Link

Describe the issue

When redeploying the gitea chart, it suddenly started complaining about not being able to create the directory /data/attachments because permissions are denied.
This is after I removed the PVC & PV from the K8s cluster. So a full clean install basically.
Last week it ran, no problem, on 1.13.2.

Version

Running chart v2.2.2
Tested on chart v2.2.3 as well, same problem
Tested on Gitea 1.13.2, 1.13.4, 1.13.5, 1.13.6 all have the same problem

Log:

 gitea Server listening on :: port 22. gitea Server listening on 0.0.0.0 port 22. gitea 2021/03/29 15:47:42 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 17 gitea 2021/03/29 15:47:42 ...dules/setting/git.go:91:newGit() [I] Git Version: 2.26.2, Wire Protocol Version 2 Enabled gitea 2021/03/29 15:47:42 routers/init.go:132:GlobalInit() [T] AppPath: /app/gitea/gitea gitea 2021/03/29 15:47:42 routers/init.go:133:GlobalInit() [T] AppWorkPath: /app/gitea gitea 2021/03/29 15:47:42 routers/init.go:134:GlobalInit() [T] Custom path: /data/gitea gitea 2021/03/29 15:47:42 routers/init.go:135:GlobalInit() [T] Log path: /app/gitea/log gitea 2021/03/29 15:47:42 routers/init.go:56:checkRunMode() [I] Run Mode: Production gitea 2021/03/29 15:47:42 ...dules/setting/log.go:297:newLogService() [I] Gitea v1.13.4 built with GNU Make 4.3, go1.15.8 : bindata, timetzdata, sqlite, sqlite_unlock_notify gitea 2021/03/29 15:47:42 ...dules/setting/log.go:343:newLogService() [I] Gitea Log Mode: Console(Console:info) gitea 2021/03/29 15:47:42 ...les/setting/cache.go:70:newCacheService() [I] Cache Service Enabled gitea 2021/03/29 15:47:42 ...les/setting/cache.go:81:newCacheService() [I] Last Commit Cache Service Enabled gitea 2021/03/29 15:47:42 ...s/setting/session.go:63:newSessionService() [I] Session Service Enabled gitea 2021/03/29 15:47:42 ...s/storage/storage.go:151:initAttachments() [I] Initialising Attachment storage with type: gitea 2021/03/29 15:47:42 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /data/attachments gitea 2021/03/29 15:47:42 routers/init.go:63:NewServices() [F] storage init failed: mkdir /data/attachments: permission denied gitea Received signal 15; terminating.

Workaround:

Add:
chmod 777 /data
to https://gitea.com/gitea/helm-chart/src/branch/master/templates/gitea/init.yaml#L18

But this could pose security issues.
And not sure how this would work/interfere with the upcoming 1.14 release

## Describe the issue When redeploying the gitea chart, it suddenly started complaining about not being able to create the directory `/data/attachments` because permissions are denied. This is after I removed the PVC & PV from the K8s cluster. So a full clean install basically. Last week it ran, no problem, on 1.13.2. ## Version Running chart v2.2.2 Tested on chart v2.2.3 as well, same problem Tested on Gitea 1.13.2, 1.13.4, 1.13.5, 1.13.6 all have the same problem ## Log: ``` gitea Server listening on :: port 22. gitea Server listening on 0.0.0.0 port 22. gitea 2021/03/29 15:47:42 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 17 gitea 2021/03/29 15:47:42 ...dules/setting/git.go:91:newGit() [I] Git Version: 2.26.2, Wire Protocol Version 2 Enabled gitea 2021/03/29 15:47:42 routers/init.go:132:GlobalInit() [T] AppPath: /app/gitea/gitea gitea 2021/03/29 15:47:42 routers/init.go:133:GlobalInit() [T] AppWorkPath: /app/gitea gitea 2021/03/29 15:47:42 routers/init.go:134:GlobalInit() [T] Custom path: /data/gitea gitea 2021/03/29 15:47:42 routers/init.go:135:GlobalInit() [T] Log path: /app/gitea/log gitea 2021/03/29 15:47:42 routers/init.go:56:checkRunMode() [I] Run Mode: Production gitea 2021/03/29 15:47:42 ...dules/setting/log.go:297:newLogService() [I] Gitea v1.13.4 built with GNU Make 4.3, go1.15.8 : bindata, timetzdata, sqlite, sqlite_unlock_notify gitea 2021/03/29 15:47:42 ...dules/setting/log.go:343:newLogService() [I] Gitea Log Mode: Console(Console:info) gitea 2021/03/29 15:47:42 ...les/setting/cache.go:70:newCacheService() [I] Cache Service Enabled gitea 2021/03/29 15:47:42 ...les/setting/cache.go:81:newCacheService() [I] Last Commit Cache Service Enabled gitea 2021/03/29 15:47:42 ...s/setting/session.go:63:newSessionService() [I] Session Service Enabled gitea 2021/03/29 15:47:42 ...s/storage/storage.go:151:initAttachments() [I] Initialising Attachment storage with type: gitea 2021/03/29 15:47:42 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /data/attachments gitea 2021/03/29 15:47:42 routers/init.go:63:NewServices() [F] storage init failed: mkdir /data/attachments: permission denied gitea Received signal 15; terminating. ``` ## Workaround: Add: `chmod 777 /data` to https://gitea.com/gitea/helm-chart/src/branch/master/templates/gitea/init.yaml#L18 But this could pose security issues. And not sure how this would work/interfere with the upcoming 1.14 release
skriesch commented 2021-04-15 13:37:35 +00:00
Contributor
Copy Link

I have got the same issue Gitea v1.13.7. The workaround does not work in my case.

Server listening on :: port 22. Server listening on 0.0.0.0 port 22. 2021/04/15 13:24:24 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 19 2021/04/15 13:24:24 ...dules/setting/git.go:91:newGit() [I] Git Version: 2.26.3, Wire Protocol Version 2 Enabled 2021/04/15 13:24:24 routers/init.go:132:GlobalInit() [T] AppPath: /app/gitea/gitea 2021/04/15 13:24:24 routers/init.go:133:GlobalInit() [T] AppWorkPath: /app/gitea 2021/04/15 13:24:24 routers/init.go:134:GlobalInit() [T] Custom path: /data/gitea 2021/04/15 13:24:24 routers/init.go:135:GlobalInit() [T] Log path: /app/gitea/log 2021/04/15 13:24:24 routers/init.go:56:checkRunMode() [I] Run Mode: Production 2021/04/15 13:24:24 ...dules/setting/log.go:297:newLogService() [I] Gitea v1.13.7 built with GNU Make 4.3, go1.15.11 : bindata, timetzdata, sqlite, sqlite_unlock_notify 2021/04/15 13:24:24 ...dules/setting/log.go:343:newLogService() [I] Gitea Log Mode: Console(Console:info) 2021/04/15 13:24:24 ...les/setting/cache.go:70:newCacheService() [I] Cache Service Enabled 2021/04/15 13:24:24 ...les/setting/cache.go:81:newCacheService() [I] Last Commit Cache Service Enabled 2021/04/15 13:24:24 ...s/setting/session.go:63:newSessionService() [I] Session Service Enabled 2021/04/15 13:24:24 ...s/storage/storage.go:158:initAttachments() [I] Initialising Attachment storage with type: 2021/04/15 13:24:24 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /data/attachments 2021/04/15 13:24:24 routers/init.go:63:NewServices() [F] storage init failed: mkdir /data/attachments: permission denied Received signal 15; terminating.
I have got the same issue Gitea v1.13.7. The workaround does not work in my case. ``` Server listening on :: port 22. Server listening on 0.0.0.0 port 22. 2021/04/15 13:24:24 cmd/web.go:108:runWeb() [I] Starting Gitea on PID: 19 2021/04/15 13:24:24 ...dules/setting/git.go:91:newGit() [I] Git Version: 2.26.3, Wire Protocol Version 2 Enabled 2021/04/15 13:24:24 routers/init.go:132:GlobalInit() [T] AppPath: /app/gitea/gitea 2021/04/15 13:24:24 routers/init.go:133:GlobalInit() [T] AppWorkPath: /app/gitea 2021/04/15 13:24:24 routers/init.go:134:GlobalInit() [T] Custom path: /data/gitea 2021/04/15 13:24:24 routers/init.go:135:GlobalInit() [T] Log path: /app/gitea/log 2021/04/15 13:24:24 routers/init.go:56:checkRunMode() [I] Run Mode: Production 2021/04/15 13:24:24 ...dules/setting/log.go:297:newLogService() [I] Gitea v1.13.7 built with GNU Make 4.3, go1.15.11 : bindata, timetzdata, sqlite, sqlite_unlock_notify 2021/04/15 13:24:24 ...dules/setting/log.go:343:newLogService() [I] Gitea Log Mode: Console(Console:info) 2021/04/15 13:24:24 ...les/setting/cache.go:70:newCacheService() [I] Cache Service Enabled 2021/04/15 13:24:24 ...les/setting/cache.go:81:newCacheService() [I] Last Commit Cache Service Enabled 2021/04/15 13:24:24 ...s/setting/session.go:63:newSessionService() [I] Session Service Enabled 2021/04/15 13:24:24 ...s/storage/storage.go:158:initAttachments() [I] Initialising Attachment storage with type: 2021/04/15 13:24:24 ...les/storage/local.go:46:NewLocalStorage() [I] Creating new Local Storage at /data/attachments 2021/04/15 13:24:24 routers/init.go:63:NewServices() [F] storage init failed: mkdir /data/attachments: permission denied Received signal 15; terminating. ```
techknowlogick commented 2021-04-15 14:01:58 +00:00
Owner
Copy Link

@Dunky13 @skriesch Which k8s distribution are both of you using, and what storage provider are you using for your PVs?

@Dunky13 @skriesch Which k8s distribution are both of you using, and what storage provider are you using for your PVs?
skriesch commented 2021-04-15 14:18:48 +00:00
Contributor
Copy Link

I am using local storage (on EC2) on my Kubernetes node on AWS.
I am using Docker in combination with Kubernetes (Rancher) on Ubuntu.

Docker version: 17.03.2-ce
Kubernetes version: v1.13.4
Linux: Ubuntu 16.04.7 LTS

My PV file for PersistentVolume (Storage Class created before):

--- apiVersion: v1 kind: PersistentVolume metadata: name: gitea-pv labels: type: local spec: accessModes: - ReadWriteMany capacity: storage: 10Gi storageClassName: gitea-manual hostPath: path: "/opt/gitea"

The PVC:

--- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gitea-gitea namespace: gitea spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: gitea-manual volumeMode: Filesystem volumeName: gitea-pv
I am using local storage (on EC2) on my Kubernetes node on AWS. I am using Docker in combination with Kubernetes (Rancher) on Ubuntu. Docker version: 17.03.2-ce Kubernetes version: v1.13.4 Linux: Ubuntu 16.04.7 LTS My PV file for PersistentVolume (Storage Class created before): ``` --- apiVersion: v1 kind: PersistentVolume metadata: name: gitea-pv labels: type: local spec: accessModes: - ReadWriteMany capacity: storage: 10Gi storageClassName: gitea-manual hostPath: path: "/opt/gitea" ``` The PVC: ``` --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: gitea-gitea namespace: gitea spec: accessModes: - ReadWriteMany resources: requests: storage: 10Gi storageClassName: gitea-manual volumeMode: Filesystem volumeName: gitea-pv ```
Dunky13 commented 2021-04-15 14:18:58 +00:00
Author
Contributor
Copy Link

K8s: 1.19.6 on AWS
Storage provider is AWS EBS with gp2 storage class

K8s: 1.19.6 on AWS Storage provider is AWS EBS with gp2 storage class
luhahn commented 2021-04-16 07:53:54 +00:00
Member
Copy Link

can you provide the output of ls -la /data ?
Also your helm chart values would be helpful

can you provide the output of ls -la /data ? Also your helm chart values would be helpful
skriesch commented 2021-04-16 08:38:13 +00:00
Contributor
Copy Link

I am able to deploy gitea with not enabled persistence (but enabled persistence for postgresql). That is the output of ls -la /data then:

bash-5.0# ls -la /data total 44 drwxrwsrwx 11 root git 4096 Apr 16 07:54 . drwxr-xr-x 1 root root 4096 Apr 16 07:54 .. drwxr-sr-x 2 git git 4096 Apr 16 07:54 attachments drwxr-sr-x 2 git git 4096 Apr 16 07:54 avatars drwxr-xr-x 3 git git 4096 Apr 16 07:54 git drwxr-xr-x 4 git git 4096 Apr 16 07:54 gitea drwxr-sr-x 4 git git 4096 Apr 16 07:54 indexers drwxr-sr-x 2 git git 4096 Apr 16 07:54 lfs drwxr-sr-x 7 git git 4096 Apr 16 07:54 queues drwxr-sr-x 2 git git 4096 Apr 16 07:54 repo-avatars drwx------ 2 root git 4096 Apr 16 07:54 ssh

One hint: I had problems with volumePermissions at PostgreSQL before, too. I have fixed that with following additional values. I tried that for gitea without success:

 volumePermissions: enabled: true

Reference for the permission issue fix: PostgreSQL Helm Blog

I am able to deploy gitea with **not enabled** persistence (but enabled persistence for postgresql). That is the output of ls -la /data then: ``` bash-5.0# ls -la /data total 44 drwxrwsrwx 11 root git 4096 Apr 16 07:54 . drwxr-xr-x 1 root root 4096 Apr 16 07:54 .. drwxr-sr-x 2 git git 4096 Apr 16 07:54 attachments drwxr-sr-x 2 git git 4096 Apr 16 07:54 avatars drwxr-xr-x 3 git git 4096 Apr 16 07:54 git drwxr-xr-x 4 git git 4096 Apr 16 07:54 gitea drwxr-sr-x 4 git git 4096 Apr 16 07:54 indexers drwxr-sr-x 2 git git 4096 Apr 16 07:54 lfs drwxr-sr-x 7 git git 4096 Apr 16 07:54 queues drwxr-sr-x 2 git git 4096 Apr 16 07:54 repo-avatars drwx------ 2 root git 4096 Apr 16 07:54 ssh ``` One hint: I had problems with volumePermissions at PostgreSQL before, too. I have fixed that with following additional values. I tried that for gitea without success: ``` volumePermissions: enabled: true ``` Reference for the permission issue fix: [PostgreSQL Helm Blog](https://www.codeproject.com/Articles/5298768/Deploy-and-Manage-PostgreSQL-on-Kubernetes)
skriesch commented 2021-04-16 09:24:52 +00:00
Contributor
Copy Link

My values.yaml:

# Default values for gitea. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 1 clusterDomain: cluster.local image: repository: gitea/gitea tag: 1.13.7 pullPolicy: Always imagePullSecrets: [] securityContext: {} service: http: type: ClusterIP port: 3000 clusterIP: None #loadBalancerIP: #nodePort: annotations: ssh: type: ClusterIP port: 22 clusterIP: None #loadBalancerIP: #nodePort: #externalTrafficPolicy: #externalIPs: loadBalancerSourceRanges: [] annotations: ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" hosts: - git.example.com tls: [] # - secretName: chart-example-tls # hosts: # - git.example.com resources: {} # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'. # limits: # cpu: 100m # memory: 128Mi # requests: # cpu: 100m # memory: 128Mi nodeSelector: {} tolerations: [] affinity: {} statefulset: env: [] # - name: VARIABLE # value: my-value terminationGracePeriodSeconds: 60 labels: {} persistence: ## Enable persistence using Persistent Volume Claims ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/ enabled: true existingClaim: gitea-gitea size: 10Gi storageClass: gitea-manual accessModes: - ReadWriteMany labels: {} annotations: {} volumePermissions: enabled: true # additional volumes to add to the Gitea statefulset. extraVolumes: # - name: postgres-ssl-vol # secret: # secretName: gitea-postgres-ssl # additional volumes to mount, both to the init container and to the main # container. As an example, can be used to mount a client cert when connecting # to an external Postgres server. extraVolumeMounts: # - name: postgres-ssl-vol # readOnly: true # mountPath: "/pg-ssl" # bash shell script copied verbatim to the start of the init-container. initPreScript: "" # # initPreScript: | # mkdir -p /data/git/.postgresql # cp /pg-ssl/* /data/git/.postgresql/ # chown -R git:git /data/git/.postgresql/ # chmod 400 /data/git/.postgresql/postgresql.key gitea: admin: username: gitea_admin password: Jr3R!gFhKL email: "gitea@local.domain" metrics: enabled: false serviceMonitor: enabled: false # prometheusSelector: default ldap: enabled: false #name: #securityProtocol: #host: #port: #userSearchBase: #userFilter: #adminFilter: #emailAttribute: #bindDn: #bindPassword: #usernameAttribute: #sshPublicKeyAttribute: oauth: enabled: false #name: #provider: #key: #secret: #autoDiscoverUrl: #useCustomUrls: #customAuthUrl: #customTokenUrl: #customProfileUrl: #customEmailUrl: config: APP_NAME: "Gitea: Git with a cup of tea" repository: ROOT: "/data/gitea-repositories" repository.pull-request: WORK_IN_PROGRESS_PREFIXES: "WIP:,[WIP]:" RUN_MODE: prod server: SSH_PORT: 22 # security: PASSWORD_COMPLEXITY: spec podAnnotations: {} database: builtIn: postgresql: enabled: true mysql: enabled: false mariadb: enabled: false cache: builtIn: enabled: true livenessProbe: enabled: true initialDelaySeconds: 200 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 10 readinessProbe: enabled: true initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 startupProbe: enabled: false initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 failureThreshold: 10 # customLivenessProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 60 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 10 # customReadinessProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 5 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 3 # customStartupProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 60 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 10 memcached: service: port: 11211 postgresql: global: postgresql: postgresqlDatabase: gitea postgresqlUsername: gitea postgresqlPassword: hT4!sQLjG5S servicePort: 5432 persistence: size: 10Gi existingClaim: gitea-mysql storageClass: gitea-manual volumePermissions: enabled: true mysql: root: password: jRhFd3SqLy!5 db: user: gitea password: JrTlDsR3W!2SaaL name: gitea service: port: 3306 persistence: size: 10Gi existingClaim: gitea-mysql storageClass: gitea-manual mariadb: auth: database: gitea username: gitea password: gitea rootPassword: gitea primary: service: port: 3306 persistence: size: 10Gi
My values.yaml: ``` # Default values for gitea. # This is a YAML-formatted file. # Declare variables to be passed into your templates. replicaCount: 1 clusterDomain: cluster.local image: repository: gitea/gitea tag: 1.13.7 pullPolicy: Always imagePullSecrets: [] securityContext: {} service: http: type: ClusterIP port: 3000 clusterIP: None #loadBalancerIP: #nodePort: annotations: ssh: type: ClusterIP port: 22 clusterIP: None #loadBalancerIP: #nodePort: #externalTrafficPolicy: #externalIPs: loadBalancerSourceRanges: [] annotations: ingress: enabled: false annotations: {} # kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" hosts: - git.example.com tls: [] # - secretName: chart-example-tls # hosts: # - git.example.com resources: {} # We usually recommend not to specify default resources and to leave this as a conscious # choice for the user. This also increases chances charts run on environments with little # resources, such as Minikube. If you do want to specify resources, uncomment the following # lines, adjust them as necessary, and remove the curly braces after 'resources:'. # limits: # cpu: 100m # memory: 128Mi # requests: # cpu: 100m # memory: 128Mi nodeSelector: {} tolerations: [] affinity: {} statefulset: env: [] # - name: VARIABLE # value: my-value terminationGracePeriodSeconds: 60 labels: {} persistence: ## Enable persistence using Persistent Volume Claims ## ref: http://kubernetes.io/docs/user-guide/persistent-volumes/ enabled: true existingClaim: gitea-gitea size: 10Gi storageClass: gitea-manual accessModes: - ReadWriteMany labels: {} annotations: {} volumePermissions: enabled: true # additional volumes to add to the Gitea statefulset. extraVolumes: # - name: postgres-ssl-vol # secret: # secretName: gitea-postgres-ssl # additional volumes to mount, both to the init container and to the main # container. As an example, can be used to mount a client cert when connecting # to an external Postgres server. extraVolumeMounts: # - name: postgres-ssl-vol # readOnly: true # mountPath: "/pg-ssl" # bash shell script copied verbatim to the start of the init-container. initPreScript: "" # # initPreScript: | # mkdir -p /data/git/.postgresql # cp /pg-ssl/* /data/git/.postgresql/ # chown -R git:git /data/git/.postgresql/ # chmod 400 /data/git/.postgresql/postgresql.key gitea: admin: username: gitea_admin password: Jr3R!gFhKL email: "gitea@local.domain" metrics: enabled: false serviceMonitor: enabled: false # prometheusSelector: default ldap: enabled: false #name: #securityProtocol: #host: #port: #userSearchBase: #userFilter: #adminFilter: #emailAttribute: #bindDn: #bindPassword: #usernameAttribute: #sshPublicKeyAttribute: oauth: enabled: false #name: #provider: #key: #secret: #autoDiscoverUrl: #useCustomUrls: #customAuthUrl: #customTokenUrl: #customProfileUrl: #customEmailUrl: config: APP_NAME: "Gitea: Git with a cup of tea" repository: ROOT: "/data/gitea-repositories" repository.pull-request: WORK_IN_PROGRESS_PREFIXES: "WIP:,[WIP]:" RUN_MODE: prod server: SSH_PORT: 22 # security: PASSWORD_COMPLEXITY: spec podAnnotations: {} database: builtIn: postgresql: enabled: true mysql: enabled: false mariadb: enabled: false cache: builtIn: enabled: true livenessProbe: enabled: true initialDelaySeconds: 200 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 10 readinessProbe: enabled: true initialDelaySeconds: 5 timeoutSeconds: 1 periodSeconds: 10 successThreshold: 1 failureThreshold: 3 startupProbe: enabled: false initialDelaySeconds: 60 periodSeconds: 10 successThreshold: 1 failureThreshold: 10 # customLivenessProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 60 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 10 # customReadinessProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 5 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 3 # customStartupProbe: # httpGet: # path: /user/login # port: http # initialDelaySeconds: 60 # periodSeconds: 10 # successThreshold: 1 # failureThreshold: 10 memcached: service: port: 11211 postgresql: global: postgresql: postgresqlDatabase: gitea postgresqlUsername: gitea postgresqlPassword: hT4!sQLjG5S servicePort: 5432 persistence: size: 10Gi existingClaim: gitea-mysql storageClass: gitea-manual volumePermissions: enabled: true mysql: root: password: jRhFd3SqLy!5 db: user: gitea password: JrTlDsR3W!2SaaL name: gitea service: port: 3306 persistence: size: 10Gi existingClaim: gitea-mysql storageClass: gitea-manual mariadb: auth: database: gitea username: gitea password: gitea rootPassword: gitea primary: service: port: 3306 persistence: size: 10Gi ```
luhahn commented 2021-04-16 12:07:10 +00:00
Member
Copy Link

I am able to deploy gitea with not enabled persistence (but enabled persistence for postgresql). That is the output of ls -la /data then:

bash-5.0# ls -la /data total 44 drwxrwsrwx 11 root git 4096 Apr 16 07:54 . drwxr-xr-x 1 root root 4096 Apr 16 07:54 .. drwxr-sr-x 2 git git 4096 Apr 16 07:54 attachments drwxr-sr-x 2 git git 4096 Apr 16 07:54 avatars drwxr-xr-x 3 git git 4096 Apr 16 07:54 git drwxr-xr-x 4 git git 4096 Apr 16 07:54 gitea drwxr-sr-x 4 git git 4096 Apr 16 07:54 indexers drwxr-sr-x 2 git git 4096 Apr 16 07:54 lfs drwxr-sr-x 7 git git 4096 Apr 16 07:54 queues drwxr-sr-x 2 git git 4096 Apr 16 07:54 repo-avatars drwx------ 2 root git 4096 Apr 16 07:54 ssh

One hint: I had problems with volumePermissions at PostgreSQL before, too. I have fixed that with following additional values. I tried that for gitea without success:

 volumePermissions: enabled: true

Reference for the permission issue fix: PostgreSQL Helm Blog

volumePermissions is bitnami specific and not implemented in the gitea helm chart. Anyways I'll have a look into this issue

> I am able to deploy gitea with **not enabled** persistence (but enabled persistence for postgresql). That is the output of ls -la /data then: > > ``` > bash-5.0# ls -la /data > total 44 > drwxrwsrwx 11 root git 4096 Apr 16 07:54 . > drwxr-xr-x 1 root root 4096 Apr 16 07:54 .. > drwxr-sr-x 2 git git 4096 Apr 16 07:54 attachments > drwxr-sr-x 2 git git 4096 Apr 16 07:54 avatars > drwxr-xr-x 3 git git 4096 Apr 16 07:54 git > drwxr-xr-x 4 git git 4096 Apr 16 07:54 gitea > drwxr-sr-x 4 git git 4096 Apr 16 07:54 indexers > drwxr-sr-x 2 git git 4096 Apr 16 07:54 lfs > drwxr-sr-x 7 git git 4096 Apr 16 07:54 queues > drwxr-sr-x 2 git git 4096 Apr 16 07:54 repo-avatars > drwx------ 2 root git 4096 Apr 16 07:54 ssh > ``` > One hint: I had problems with volumePermissions at PostgreSQL before, too. I have fixed that with following additional values. I tried that for gitea without success: > ``` > volumePermissions: > enabled: true > ``` > Reference for the permission issue fix: [PostgreSQL Helm Blog](https://www.codeproject.com/Articles/5298768/Deploy-and-Manage-PostgreSQL-on-Kubernetes) volumePermissions is bitnami specific and not implemented in the gitea helm chart. Anyways I'll have a look into this issue
luhahn commented 2021-04-16 13:17:26 +00:00
Member
Copy Link

Ok, so it seems, that some storageClasses have issues with securityContext.fsgroup, which is used to mount as group git, which allows the container to access /data properly.

I could recreate this issue by using hostpath storage, which completly ignores the fsgroup. However I can't reproduce this on AWS since i don't have an account to test the storage.

My current solution is quite similar to @Dunky13 chmod but I use chown 1000:1000 on /data, which only allows the git user to access the directory this should also be okay with the 1.14 version.

Should be fixed with #144

Ok, so it seems, that some storageClasses have issues with securityContext.fsgroup, which is used to mount as group git, which allows the container to access /data properly. I could recreate this issue by using hostpath storage, which completly ignores the fsgroup. However I can't reproduce this on AWS since i don't have an account to test the storage. My current solution is quite similar to @Dunky13 chmod but I use chown 1000:1000 on /data, which only allows the git user to access the directory this should also be okay with the 1.14 version. Should be fixed with #144
👍 2 ❤️ 1 🎉 2
skriesch commented 2021-04-16 14:16:24 +00:00
Contributor
Copy Link

I have tested this fix. It does not work with hostPath. Perhaps I should switch to gp2.

I have tested this fix. It does not work with hostPath. Perhaps I should switch to gp2.
luhahn commented 2021-04-16 14:46:09 +00:00
Member
Copy Link

Weird, i tested with hostPath and it worked fine. Can you show your storage class?

Weird, i tested with hostPath and it worked fine. Can you show your storage class?
skriesch commented 2021-04-16 14:53:51 +00:00
Contributor
Copy Link

That could be my problem. I thought I would be using an existing StorageClass by our team:

 #kubectl get storageclass No resources found

Thank you for the hint!

That could be my problem. I thought I would be using an existing StorageClass by our team: ``` #kubectl get storageclass No resources found ``` Thank you for the hint!
skriesch commented 2021-04-16 15:51:53 +00:00
Contributor
Copy Link

I have created the storageClass now:

 kubectl get storageclass NAME PROVISIONER AGE gitea-manual kubernetes.io/no-provisioner 8m17s

But I am receiving the same error message...

My storage class configuration:

kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gitea-manual provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer
I have created the storageClass now: ``` kubectl get storageclass NAME PROVISIONER AGE gitea-manual kubernetes.io/no-provisioner 8m17s ``` But I am receiving the same error message... My storage class configuration: ``` kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: gitea-manual provisioner: kubernetes.io/no-provisioner volumeBindingMode: WaitForFirstConsumer ```
skriesch commented 2021-04-19 07:29:28 +00:00
Contributor
Copy Link

Sorry! That was my mistake. I have tried the stable branch instead of the fix. Yes. It is working now with a local clone of your fix.

Thank you!

Sorry! That was my mistake. I have tried the stable branch instead of the fix. Yes. It is working now with a local clone of your fix. Thank you!
👍 1
luhahn commented 2021-04-19 12:30:55 +00:00
Member
Copy Link

merged #144

merged #144
violetbooth commented 2022-03-30 12:35:17 +00:00
Copy Link

Hey! I am glad that I read your blog; you have clearly explained the responsibilities of freelance developers. I also came across one of the freelancing platforms that are Eiliana.com; they help you connect with top developers. I hope that helps you.

Hey! I am glad that I read your blog; you have clearly explained the responsibilities of freelance developers. I also came across one of the freelancing platforms that are Eiliana.com; they help you connect with [top developers](https://eiliana.com/blogitem/app-development-companies-in-india-a-preferred-choice). I hope that helps you.
Sign in to join this conversation.
v2.2.2
Branches Tags
Labels
Clear labels
has
backport
in progress
invalid
kind
breaking
kind
bug
kind
build
kind
dependency
kind
deployment
kind
docs
kind
enhancement
kind
feature
kind
lint
kind
proposal
kind
question
kind
refactor
kind
security
kind
testing
kind
translation
kind
ui
need
backport
priority
critical
priority
low
priority
maybe
priority
medium
reviewed
duplicate
reviewed
invalid
reviewed
wontfix
skip-changelog
status
blocked
status
needs-feedback
status
needs-reviews
status
wip
upstream
gitea
upstream
other
workaround
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
42wim 6543 a1012112796 Akkuman appleboy axifive betacat0 blumia bwko caicandong ChristopherHX DaanSelen davidsvantesson delvh denyskon fuxiaohei gary-kim garymoon giteabot guillep2k HesterG hiifong jaqra jolheiser jonasfranz jpraet kdumontnu kemzeb kerwin612 khmarbaise KN4CK3R kolaente lafriks lng2020 lotherk luhahn lunny mrsdizzie noerw pat-s puni9869 renovate-bot richmahn rossigee sapk screenshots sillyguodong silverwind smartclip_tim strk tboerger techknowlogick TheFox0x7 tobiasbp typeless volker.raschek wolfogre wxiaoguang yardenshoham yp05327 zeripath Zettat123
No Assignees
5 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: gitea/helm-gitea#135
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?