Apache permission denied when binding to address
Nobody has claimed this yet.
- Dominant language
- Go Template
- Stars
- 534
- Forks
- 314
- Avg merge
- 42m
- Merged PRs (30d)
- 1
Description
Describe your Issue
Nextcloud doesn't start because of apache not being able to bind to port 80. I tried to set the sysctls option, I tried runAsNonRoot false, changing the containerPort to a non privileged port, but nothing works.
I'm using a traefik reverse proxy as an ingress controller which is confgured correctly(it is used for all our production stacks).
Logs and Errors
| Initializing nextcloud 30.0.6.2 ... │
│ New nextcloud instance │
│ Installing with PostgreSQL database │
│ => Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-installation │
│ Starting nextcloud installation │
│ Nextcloud was successfully installed │
│ Setting trusted domains… │
│ System config value trusted_domains => 1 set to string xxxxxxxxxxxxxxx │
│ => Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/post-installation │
│ Initializing finished │
│ => Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/before-starting │
│ AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.11.19.106. Set the 'ServerName' directive globally to suppress this message │
│ (13)Permission denied: AH00072: make_sock: could not bind to address [::]:80 │
│ (13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80 │
│ no listening sockets available, shutting down │
│ AH00015: Unable to open logs
Describe your Environment
-
Kubernetes distribution: eks
-
Helm Version (or App that manages helm): helm v3.16.2
-
Helm Chart Version: 6.6.9
-
values.yaml:
image:
pullPolicy: Always
phpClientHttpsFix:
enabled: false
protocol: https
nextcloud:
host: xxxxxxxxxxxxxxxx
username: admin
password: xxxxxxxxxxxxxx
containerPort: 80
datadir: /var/www/html/data
securityContext:
runAsUser: 50002
runAsNonRoot: true
sysctls:
- name: net.ipv4.ip_unprivileged_port_start
value: "0"
objectStore:
s3:
enabled: true
accessKey: "xxxxxxxxx"
secretKey: "xxxxxxx"
ssl: true
port: "443"
region: "xxxxxxxxxxxxx"
bucket: "xxxxxxxxxxx"
# Extra config files created in /var/www/html/config/
# ref: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#multiple-config-php-file
configs: {}
# For example, to enable image and text file previews:
# previews.config.php: |-
# <?php
# $CONFIG = array (
# 'enable_previews' => true,
# 'enabledPreviewProviders' => array (
# 'OC\Preview\Movie',
# ),
# );
internalDatabase:
enabled: false
externalDatabase:
enabled: true
type: postgresql
host: "aurora1.xxxxxxxxx.com"
user: xxxxxxxx
password: "xxxxxx"
database: xxxxxx
persistence:
enabled: true
storageClass: "efs-sc"
accessMode: ReadWriteOnce
size: 8Gi
livenessProbe:
enabled: false
initialDelaySeconds: 120
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
readinessProbe:
enabled: false
initialDelaySeconds: 120
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
startupProbe:
enabled: false
initialDelaySeconds: 120
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 30
successThreshold: 1
Additional context, if any
We're using NFS for persistance using AWS EFS, it works fine. We're using Aurora PostgreSQL as a database, it works fine too. I turned off the probes temporarily because the initialization lasts for 5-10 minutes.
I've set runAsUser: 50002 because that was the only way to make storage permissions work.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin with the supplied values.yaml, especially nextcloud.securityContext, containerPort, and the Kubernetes deployment generated by the Helm chart. Reproduce the Apache startup failure in EKS and trace the rendered security settings; done means the chart starts successfully while retaining the reported non-root storage configuration.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- apache, aws, helm, kubernetes, postgresql
- Domain
- cloud, devops, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100