Remove chmod workaround in nextcloud image

[eriksjolund]

I added the line

nextcloud-podman/Dockerfile.nextcloud

Line 2 in 33e32e3

RUN chmod 777 /usr/local/etc/php/conf.d/

to work around an error. (I don't remember the details).
Remove the line and create a more secure fix.

[Shadow8472]

I might have some additional context. Though my setup isn't to Quadlets yet, I have a pod set up to produce the same UID/GID as the calling rootless user (doesn't work for .hidden_files!). MariaDB and Redis are listed as Running, but Nextcloud is spamming:

/entrypoint.sh: 111: cannot create /usr/local/etc/php/conf.d/redis-session.ini: Permission denied

[Shadow8472]

I'm past the spamming issue thanks to this comment:
nextcloud/docker#763 (comment)

Based off discussion, (either around this issue or one linking back to it), I gather it's a Nextcloud container bug when running rootless -- possibly introduced at some point by changes to Docker/Podman, as I do not remember facing this issue when working with Podman 3.0.1.

Either case, I got new errors when I created a redis-session.ini to mount it as a volume. I'm unsure how this workaround compares in terms of security to the one currently implemented.

[eriksjolund]

I wonder if adding --user 0:0, would make a change. When I created this repo I thought --userns keep-id:uid=$gid,gid=$gid was unrelated to the container UID:GID of the first container process but I noticed last week that it is changed to $uid:$gid.

[eriksjolund]

Either case, I got new errors when I created a redis-session.ini to mount it as a volume. I'm unsure how this workaround compares in terms of security to the one currently implemented.

Do you use bind-mounted dirs or volumes?
In other words --volume ./dir:dir or --volume volumename:dir?
Probably it doesn't matter but I would first try it out with bind-mounted directories as it is a less complicated operation.

[Shadow8472]

I'm using directories. -v /full/host/path/to/directory:/container/dir:z I have a non-root podmanuser with a projectNameBase directory for each project. I'm hosting redis-session.ini in ~/nextcloudBase with permissions 644.

I've not made a serious effort to sift through the log (it's Thanksgiving in the US, and I intend to spend most of it with family), but here is one of its current loops. I'm thinking my next step might need to be to bring up PiHole and Caddy to get Nextcloud its domain name.

=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/before-starting
==> but the hook folder "before-starting" is empty, so nothing to do
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.88.2.3. 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
Configuring Redis as session handler

And just in case, here's what I'm looking at for my WIP reset script (Redis doesn't like working with secrets for some reason).

echo stop and remove pod
podman pod stop NextcloudRedLaptop
podman pod rm NextcloudRedLaptop
echo podman pod create NextcloudRedLaptop
podman pod create \
        --name NextcloudRedLaptop \
        --network podman \
        --userns=keep-id:uid=999,gid=999 \
        --ip 10.88.2.3
#       -p 8002:80
#       -v MariaDBVolume:/var/lib/mysql:Z \
#       -v nextcloudFastVolume:/var/www/html:Z \
#       -v nextcloudPhotoVolume:/var/www/html/data/Photos:z \

echo podman create MariaDB
podman create \
        --pod NextcloudRedLaptop \
        --name MariaDBContainer \
        -v /home/podmanuser/nextcloudBase/MariaDBDummy:/var/lib/mysql:z \
        --secret DBrootPass \
        -e MARIADB_ROOT_PASSWORD=/run/secrets/rootPassword \
        -e MARIADB_DATABASE=NextcloudDB \
        -e MARIADB_USER=nextcloudDbUser \
        --secret DBpass \
        -e MARIADB_PASSWORD=/run/secrets/password \
        --restart on-failure \
        docker.io/library/mariadb:latest

echo podman create Redis
podman create \
        --pod NextcloudRedLaptop \
        --name RedisContainer \
        --restart on-failure \
        docker.io/library/redis:latest \
        --requirepass "RedisPass"

echo podman create Nextcloud
podman create \
        --pod NextcloudRedLaptop \
        --name NextcloudContainer \
        -v /home/podmanuser/nextcloudBase/NextcloudFastDummy:/var/www/html:z \
        -v /home/podmanuser/nextcloudBase/redis-session.ini:/usr/local/etc/php/conf.d/redis-session.ini:z \
        -e REDIS_HOST="127.0.0.1" \
        -e MYSQL_DATABASE=NextcloudDB \
        -e MYSQL_USER=nextcloudDbUser \
        --secret DBpass \
        -e MYSQL_PASSWORD=/run/secrets/password \
        -e MYSQL_HOST=127.0.0.1:3306 \
        --restart on-failure \
        -e REDIS_PASSWORD="RedisPass" \
        docker.io/library/nextcloud:latest
#       -v /mnt/PhotoTrunk/nextcloudPhotoVault: \
#       --secret RedisPass \


# -e MYSQL_HOST=NextcloudPodDB:3306

echo podman start NextcloudPod
podman pod start NextcloudRedLaptop

[eriksjolund]

In the error message output:

(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

That error would happen if the ip_unprivileged_port_start value is higher than 80.

$ cat /proc/sys/net/ipv4/ip_unprivileged_port_start
1024

some ideas:

alternative solution 1

Some instructions of how to modify the setting:
https://rootlesscontaine.rs/getting-started/common/sysctl/#allowing-listening-on-tcp--udp-ports-below-1024

alternative solution 2

Maybe the --userns=keep-id:uid=999,gid=999 that was set on the pod influences the container user for the nextcloud container? Maybe adding --user 0:0 when running the nextcloud container would fix the could not bind to address error messages?

A side-note:

Caddy to get Nextcloud its domain name.

I just want to mention a very experimental approach to setting up a reverse proxy that is listening on port 80 and at the same time is running rootless podman: Use a systemd system service with User=.
I tried just tried it out for nginx. See example3 and example4 here:
https://github.com/eriksjolund/podman-nginx-socket-activation/tree/main
Note, I have almost not done any testing. I've just verified that a basic curl command was able to download index.html
from the nginx container.

[Shadow8472]

What I know is I'm totally burned out from focusing on this topic this month. I'll be back, but I want to do some less intense blog topics over December and come back at it in the new year. My immediate goal is to get PiHole and Caddy into Quadlets so I have something to work off of come January. I'm to the point of generating Kubernetes .yml files for running pods.

[Shadow8472]

For the record, Alternate Solution 2 as implemented by setting --user 0:0 to the container (leaving the pod at --userns=keep-id:uid=999,gid=999) resulted in the same log including (13)Permission denied: AH00072: make_sock: could not bind to address [::]:80