Cache has wrong permissions

[alexhorn]

When trying to save settings (e.g. global time zone), the following error is shown:

Uuuups ... Du hast womöglich den falschen Weg eingeschlagen.
Es ist ein interner Fehler aufgetreten.

The logs show this error:

humhub_1  | 2021-04-26 12:27:38 [172.18.0.2][-][-][warning][yii\caching\FileCache::setValue] Unable to write cache file '/var/www/localhost/htdocs/protected/runtime/cache/55/humhub55faa527c8996473568237dc780d430d.bin': file_put_contents(/var/www/localhost/htdocs/protected/runtime/cache/55/humhub55faa527c8996473568237dc780d430d.bin): failed to open stream: Permission denied

Apparently the permission files are owned by root and are set to 644 so that the PHP process can not access them.

Did we do something wrong?

[mriedmann]

Hi and thx for your Report.

Sadly, I can't reproduce your error. Can you please post the Humhub version, Image version (Hash or Tag) and Conteiner-Config (docker-compose or docker-command you used to start).

[alexhorn]

We are running HumHub 1.8.1 from the mriedmann/humhub:1.8 image.

Here's our docker-compose.yml:

version: '3.1'
services:
  humhub:
    image: mriedmann/humhub:1.8
    restart: always
    links:
      - "db:db"
    volumes:
      - ./humhub_config:/var/www/localhost/htdocs/protected/config
      - ./humhub_uploads:/var/www/localhost/htdocs/uploads
      - ./humhub_modules:/var/www/localhost/htdocs/protected/modules
    environment:
      HUMHUB_DB_USER: humhub
      HUMHUB_DB_PASSWORD: redacted
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.humhub.rule=Host(`redacted`)"
      - "traefik.http.routers.humhub.entrypoints=https"
      - "traefik.http.routers.humhub.tls=true"
      - "traefik.http.routers.humhub.tls.certresolver=le"
    networks:
      - web
      - internal

  db:
    image: mariadb:10.2
    restart: always
    volumes:
      - ./humhub_db:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: redacted
      MYSQL_DATABASE: humhub
      MYSQL_USER: humhub
      MYSQL_PASSWORD: redacted
    networks:
      - internal

networks:
  web:
    external: true
  internal:
    external: false

[alexhorn]

It seems like this was our mistake. Somehow our permissions were all set to root:root. I didn't consider this as a possible issue because the /runtime folder from our error messages isn't mounted as a volume, but for whatever reason the following commands seem to have fixed our problems:

chown -R nginx:nginx /var/www/localhost/htdocs/uploads
chown -R nginx:nginx /var/www/localhost/htdocs/protected/modules
chown -R nginx:nginx /var/www/localhost/htdocs/protected/config
chown -R nginx:nginx /var/www/localhost/htdocs/protected/runtime

Maybe running chown on every container startup would be an idea to consider?

Anyways, sorry for the inconvenience.

[ArchBlood]

You should always chown every container startup when given the chance to, else permission issues will occur such as this one

[mriedmann]

very interesting. The thing with chmod is, that using it reliably requires the container-user to be root. This is true for most docker installations, but isn't for some container platforms like OpenShift or other enterprise Kubernetes distributions. I would like to avoid running chown on every startup, also because it can significantly increase bootup times on large volumes with many files.
The interesting question here would be: How did this happen and is it something that can happen easily to other people as well.
I am open to suggestions, but also want to make sure that we going in the right direction here.

[timwsuqld]

@mriedmann can you please reopen this. It's an issue with the container startup. The cache has the incorrect permissions initially.

docker run --rm --entrypoint /bin/ls mriedmann/humhub:1.8 -l /var/www/localhost/htdocs/protected/runtime/ shows the cache directory doesn't exist at container startup. Yet on my instance, by the time the entrypoint has run, the cache exists and is owned by root. I think it's one of the many php yii commands that is getting run at some point (i.e. database migrations) and because it runs as root, the cache is owned by root. If I then remove the container and start it fresh ((no migrations to run) then it works fine.

We really just need chown nginx:nginx -R /var/www/localhost/htdocs/protected/runtime/ near the end of docker-entrypoint.sh

[mriedmann]

In most cases the cache dir would reside in a bind-mount so it isn't lost on container recreation. But, we can add it to the "install" part of the entry-point if you think this is needed (https://github.com/mriedmann/humhub-docker/blob/master/docker-entrypoint.sh#L132)
Will reopen this till we have a solution for your problem.

[alexhorn]

Our permissions somehow broke again, but this time it was the search which didn't work anymore:

2021-10-06 17:15:22 [172.18.0.2][4][i8r2onj14ivgpi1o2mhoitric8][error][ZendSearch\Lucene\Exception\RuntimeException] ZendSearch\Lucene\Exception\RuntimeException: fopen(/var/www/localhost/htdocs/protected/runtime/searchdb/_48.sti): failed to open stream: Permission denied in /var/www/localhost/htdocs/protected/vendor/matthewbdaly/zendsearch/src/ZendSearch/Lucene/Storage/File/Filesystem.php:56

Running the chown commands I posted above fixed the problem.

[timwsuqld]

@mriedmann Not sure why you think the cache dir would be in a bind-mount? None of the example run commands or docker-compose files have /var/www/localhost/htdocs/protected/runtime/ in any of the mounts, only /var/www/localhost/htdocs/protected/config/ and /var/www/localhost/htdocs/protected/modules/.

In my testing the chown is just running too early when an install section is run, it's probably best to move/duplicate the chown towards the end of the entrypoint given that the entrypoint runs as root.

[alexhorn]

Our permissions keep breaking whenever I update to a new HumHub version. I think @timwsuqld is right and something about the migration resets the permissions.

[PierreJiji]

Is there any update on this issues please? I have encountered the same issue in my installations on OpenShift.
Thank you for your assistance !

[mriedmann]

k8s and openshift is its own beast. Currently we depend on the right to modify permissions to some dirs on startup. The problem here is that this issue and the issue that you might have are not exactly the same.

You can try to add an emptyDir volume and mount it at /var/www/localhost/htdocs/protected/runtime/cache this can help (if your problem is really the same as described here)
Have a look here: https://www.alibabacloud.com/blog/kubernetes-volume-basics-emptydir-and-persistentvolume_594834
Keep in mind that an emptydir mount is temporary and gets deleted on easy pod recreation. For a cachedir this might suffice.

[blackandred]

It seems like this was our mistake. Somehow our permissions were all set to root:root

I think it may be some mistake during the container startup or somewhere in a cronjob, because lots of thing are running as root there.

Btw, I'm not sure, but this may possibly resolve the issue: #308

[PierreJiji]

k8s and openshift is its own beast. Currently we depend on the right to modify permissions to some dirs on startup. The problem here is that this issue and the issue that you might have are not exactly the same.

You can try to add an emptyDir volume and mount it at /var/www/localhost/htdocs/protected/runtime/cache this can help (if your problem is really the same as described here) Have a look here: https://www.alibabacloud.com/blog/kubernetes-volume-basics-emptydir-and-persistentvolume_594834 Keep in mind that an emptydir mount is temporary and gets deleted on easy pod recreation. For a cachedir this might suffice.

Hi,
Thank you for ur replay,
It's much better with a volume, but you still need to run this command line chmod 777 -R /var/www/localhost/htdocs/protected/runtime/cache/* because the root user creates cache files during container creation.

[Damien2s]

Just to mentioned that I encounter the same cache issue running the latest image.
And fixed it with:
chown -R nginx:nginx /var/www/localhost/htdocs/protected/runtime

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.