gitea/helm-chart
45
54
Fork 127
Code Issues 33 Pull Requests 9 Actions Releases 87 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
Clear current reference
main
quote-image-tag
app-ini-recreation
fix-env-to-ini
clean-app-ini
gitea-ha
Clear current reference
v10.1.4
v10.1.3
v10.1.2
v10.1.1
v10.1.0
v10.0.2
v10.0.1
v10.0.0
v9.6.1
v9.6.0
v9.5.1
v9.5.0
v9.4.0
v9.3.0
v9.2.1
v9.2.0
v9.1.0
v9.0.4
v9.0.3
v9.0.2
v9.0.1
v9.0.0
v8.3.0
v8.2.0
v8.1.0
v8.0.3
v8.0.2
v8.0.1
v8.0.0
v7.0.4
v7.0.3
v7.0.2
v7.0.1
v7.0.0
v6.0.5
v6.0.4
v6.0.3
v6.0.2
v6.0.1
v6.0.0
v5.0.9
v5.0.8
v5.0.7
v5.0.6
v5.0.5
v5.0.4
v5.0.3
v5.0.2
v5.0.1
v5.0.0
v4.1.1
v4.1.0
v4.0.3
v4.0.2
v4.0.1
v4.0.0
v3.1.4
v3.1.3
v3.1.2
v3.1.1
v3.1.0
v3.0.0
v2.2.5
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.11
v2.1.10
v2.1.9
v2.1.8
v2.1.7
v2.1.6
v2.1.5
v2.1.4
v2.1.3
v2.1.2
v2.1.1
v2.1.0
v2.0.7
v2.0.6
v2.0.5
v2.0.4
v2.0.3
v2.0.2
v2.0.0
v1.5.5
v1.5.4
v1.5.3
v1.5.2
v1.5.1
v1.5.0
v1.4.9
v1.4.8
v1.4.7
v1.4.6
v1.4.5
v1.4.4
v1.4.3
v1.4.2
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

No Label
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
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/helm-chart#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?