Latest image broken - static files in /var/www/html/public_html won't served

[foorschtbar]

Since updating the container tonight to the latest apache image, Roundcube won't serve any static files:

roundcube-app        | xxx - - [26/Feb/2025:12:36:14 +0000] "GET / HTTP/1.0" 200 2934 "-" "xxx"
nginx-mailcow-1      | xxx - - [26/Feb/2025:13:36:14 +0100] "GET /rc/ HTTP/2.0" 200 2471 "-" "xxx"
roundcube-app        | [Wed Feb 26 12:36:14.170935 2025] [core:error] [pid 166:tid 166] [client xxx:50896] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/public_html/skins, referer: https://xxx

Maybe this had something to do with #321? I'm not sure if it's my setup or if the new image had a problem.

I can see that there a now symbolic links, but its disabled in apache config?

root@xxx:/var/www/html/public_html# ls -la
total 16
drwxrwxr-x  3 1000 1000 4096 May 19  2024 .
drwxr-xr-x 12 1000 1000 4096 Feb 14 02:00 ..
lrwxrwxrwx  1 1000 1000   12 May 19  2024 .htaccess -> ../.htaccess
-rw-rw-r--  1 1000 1000 1434 May 19  2024 index.php
lrwxrwxrwx  1 1000 1000   10 May 19  2024 plugins -> ../plugins
drwxrwxr-x  2 1000 1000 4096 May 19  2024 program
lrwxrwxrwx  1 1000 1000    8 May 19  2024 skins -> ../skins

[pabzm]

I can not reproduce that so far. Could you let me know:

• which container tools do you use?
• what are the image IDs and digests you are using?
• Do you mount any volumes?

[foorschtbar]

• roundcube/roundcubemail:latest (6b70a1a2e67b7f2cb54b011fe1b3aebf76695dc0b84d49a171eed27113f0a78f)
• compose file:

[...]
  roundcube-app:
    image: roundcube/roundcubemail
    container_name: roundcube-app
    restart: unless-stopped
    environment:
      - ROUNDCUBEMAIL_SKIN=elastic
[...]
    volumes:
      - ./volumes/roundcube/html:/var/www/html
      - ./volumes/roundcube/config/:/var/roundcube/config
    labels:
      # Watchtower
      - com.centurylinklabs.watchtower.enable=true
    depends_on:
      - roundcube-db
    [...]

[pabzm]

Are you using Docker? Or something else?

What is the image digest? (6b70a1a2e67b7f2cb54b011fe1b3aebf76695dc0b84d49a171eed27113f0a78f is probably the ID?)

[nielslammers]

FWIW, I seem to have the exact same behavior mentioned by @foorschtbar

`[Wed Feb 26 15:40:33.967253 2025] [core:error] [pid 132:tid 132] [client 10.0.1.6:50834] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/public_html/skins, referer: https://webmail.quaqua.nl/
10.0.1.6 - - [26/Feb/2025:15:40:33 +0000] "GET /skins/elastic/deps/bootstrap.min.css?s=1739004467 HTTP/1.1" 403 443 "https://webmail.quaqua.nl/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:135.0) Gecko/20100101 Firefox/135.0"
[Wed Feb 26 15:40:33.968362 2025] [core:error] [pid 133:tid 133] [client 10.0.1.6:50840] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/public_html/skins, referer: https://webmail.quaqua.nl/`

digest: ff6db776c5ccac83be60109aca602d548413acbcda293ca13c512eb9fcf238b4
ID: 82bcd0fb92bbe30cfbff10eea14aaec28b04f3a3bca6cfd9dbae625f057ed097

But I highly suspect it already existed on a somewhat older image
digest: 4820b69532066372d66c23ccb7ec56d1d55560c929a83b0999750b562bb7f199
ID: 03228a6dc2cefaf15d08aa345c989b6df5ae7ecff0b8dcf245f0924a6fb395dd

as I pulled the very latest image to see if it would solve the problem I was already having.

[foorschtbar]

Are you using Docker? Or something else?

Sorry, yes Docker CE.

What is the image digest? (6b70a1a2e67b7f2cb54b011fe1b3aebf76695dc0b84d49a171eed27113f0a78f is probably the ID?)

Yes, sorry. Digest: sha256:ff6db776c5ccac83be60109aca602d548413acbcda293ca13c512eb9fcf238b4

But its now working after deleting the html folder and restarting the container.

[nielslammers]

[Wed Feb 26 15:40:33.968362 2025] [core:error] [pid 133:tid 133] [client 10.0.1.6:50840] AH00037: Symbolic link not allowed or link target not accessible: /var/www/html/public_html/skins, referer: https://webmail.quaqua.nl/`

I mount /var/www/html as separate volume as well, but took a slightly different approach:
Just fixed my setup by 'chowning' these directories outside the public_html dir to the same userid that was already there for public_html:

• plugins
• program
• skins

Before I did that these had ownership root:root, which explains the errors.

Thanks for the hints here :-)

[foorschtbar]

I checked my backups, the files hat user:user as owner. After restoring and changing it to root:root, it also works.

[nielslammers]

Interesting observation @foorschtbar , which got me think a bit further.
As the directories that the links point to are world-readable, I also thought it should have worked to begin with, but now I see that it looks like the owner of the symbolic link in public_html actually needs to match the owner of the directory that the link points to.

So, yes, with ownership root:root of the skins/program/plugins directories it also works for me as long as I change the ownership of the symlinks in public_html, i.e. delete them and re-create them as root.
So, either a change in the ownership of the directories pointed to OR the ownership of the symbolic link, but they need to match in order to work (in my case anyway).

I'm sure someone will tell me that this is well-documented behavior of symbolic links, but I never quite realized it I guess.