Closed svengreb closed 8 months ago
Also to clarify some possible question beforehand:
SERVICE_URL
and FILE_SERVER_ROOT
properties are both set to the correct URL and the URL of the avatar request reflect these configurations.USE_X_FORWARDED_HOST = True
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
to my seahub_settings.py
file (like mentioned and often marked as solution in some forum threads) to ensure the header is allowed and passed through. I've configured my Traefik router to also allow this header being passed though.
/tmp/seahub_cache
directory that I could delete, but I always made sure to wipe the memcached container after testing other configurations./shared/seafile/conf/__pycache__
directory to make sure there are no cached configuration values when restarting the container.@svengreb I just encountered the same issue, and looks like I've found the reason.
nginx is configured to use the directories avatars
and custom
inside the /opt/seafile/seafile-server-latest/seahub/media
directory. But avatars
and custom
are symlinks and effectively located inside /shared/seafile/seahub-data
. Unfortunately nginx (running as www-data
user) is not able to access this directory because /shared
is set to 750 permissions. chmod o=rx /shared
fixes this issue.
@freeplant If you want I can create a PR for this issue but I'm not familiar with the scripts and unsure where to put the fix.
Same problem here
I followed the official guide about how to deploy Seafile with Docker and everything worked fine except avatar images. All requests to the
/media/avatars/*
route fail with a403 Permission Denied
response. Other requests to sub-routes of/media
like e.g./media/assets/*
and/media/fontawesome
succeed without problems so CSS and JS files are loaded.I'm using the recommended configurations for Docker Compose by mounting the
/shared
path of theseafile
service container to my Docker host system. I checked that all paths have the correct filesystem attributes (ownerroot:root
) to be sure that this is not the root cause. I also checked the data structure and layout within the container and noticed that the directory that contains the avatars/opt/seafile/seafile-server-latest/seahub/media/avatars
is actually a relative symbolic link (../../../seahub-data/avatars
) that resolves to/shared/seafile/seahub-data/avatars
. The target path is located within the mounted volume and I verified that the files of my custom avatar images exist and also have the correct filesystem permissions. Strangely enough requests for my custom background image for the login page work totally fine even though the actual directory is a relative symbolic link to/shared/seafile/seahub-data/custom
and the target directory is also within the mounted volume.Analysis Findings
I found a location block in the nginx configuration that is included in the Docker image by default:
https://github.com/haiwen/seafile-docker/blob/873656cd59a426bce0acf27b3b821dad046f486d/image/seafile_7.1/templates/seafile.nginx.conf.template#L85-L87
I wondered why this block is defined at all because there are no other location blocks for other routes like e.g.
/api
. I removed the whole location block for the/media
path to see if this breaks requests to CSS/JS resources, but instead all requests succeeded including the ones for custom avatars.Can someone from the team explain what the exact purpose of the
location /media
is? Is this required for the frontend framework (Django)? I also checked the commit history of this code snippet and it looks like it was added for the first time 4 months ago in c75d241e7868de24560855abf1554d9350c4d8dc.Reproduction Steps
This step-by-step list should make it possible to reproduce the problem:
sudo docker-compose up -d
/media/avatars/*
are failing (403
Permission Denied) even when no custom avatar image has been set yet. Also check that other requests to the/media
sub-route (e.g./media/assets
) succeed and CSS/JS files are loaded and applied correctly to the web UI.sudo docker exec -it seafile /bin/bash
) and remove thelocation /media
block from the/shared/nginx/conf/seafile.nginx.conf
file (lines 52 to 54).sudo docker-compose restart
/media/avatars/*
are now succeeding (200
OK) as well as other CSS/JS requests (/media/assets
).Possible Root Cause Starting Points
I've never really been a fan of nginx and only used and configured it because it was a requirement (job related projects), but I found a “Root inside Location Block“ section in their official “Pitfalls and Common Mistakes“ documentation which looks like it matches the defined block in the SeaHub source code.