Seafile Server Permission denied :(

Hi Community!

Hope you can help me, I think my issue is trivial but I can’t find anything about that…

The first steps work fine: Seafile is launched via Docker, I can connect to my instance in HTTPS and navigate on my Seafile website. However, once I try to change something on the admin section, I have a permission denied.

I didn’t find anything on the logs :confused:

My setup:

  • A firewall;
  • A Nginx Server;
  • A server hosting Docker where Seafile is configured.

More informations:

  • I have my own domain,
  • DNS redirection works fine as I access to the WebUI;
  • Seafile (v7.1.5 CE) works fine in LAN without HTTPS…

Here a picture:

I saw some post but any of them was relevant…


PS: I also tried without Docker, I installed Seafile in /opt and I meet the same error message.


Edit: I saw the message from @mercury and just realize that I didn’t give the Seafile version :grimacing:

I’m seeing the same thing. Just upgraded to 8.0.2 CE from 7.1.5 CE (Nginx, Ubuntu 18.04 LTS).

Can’t create files or folders, move files, rename files, or email shared links.

I can view files and edit (save) text files. Sync from Desktop works.

From seahub.log:

First event: try to create new folder
Second event: try to create new text file

2021-01-18 18:11:30,891 [WARNING] django.request:228 log_response Forbidden: /api2/repos/0e2d3f0d-b72f-4127-bfad-7af0e7b59cf6/dir/
2021-01-18 18:13:39,576 [WARNING] django.request:228 log_response Forbidden: /api/v2.1/repos/0e2d3f0d-b72f-4127-bfad-7af0e7b59cf6/file/

Repo is read/write for Seafile user.

Does this make sense for Django?

$ django-admin --version


Just resolved my issue thanks to Cannot delete or move files at web UI - 403 forbidden

I added the following content to my Nginx site configuration, do a reload and tada, it works!

proxy_set_header        Cookie $http_cookie;
proxy_cookie_path   ~*^/.* "~*^/.* HTTPOnly; Secure";

Documentation should really be more clear. Hope this helps you @mercury!

1 Like

Where do you put these in your Nginx config?

What else do you have for cookies in your Nginx config? Added both and now can’t login in.

The page isn’t redirecting properly
This problem can sometimes be caused by disabling or refusing to accept cookies.


as you quoted my solution I need to say sorry that I didn’t edit it afterwards. That solved my problem, when I was logged in but as you experienced too this proxy_cookie_path breaks the redirecting. I simply commented it out in my nginx.conf.

Here is my working nginx.conf and vhost.conf

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/;

include /usr/share/nginx/modules/*.conf;

events {
worker_connections 1024;

http {
    log_format       main       '$remote_addr - $remote_user [$time_local] "$request" '
                                '$status $body_bytes_sent "$http_referer" '
                                '"$http_user_agent" "$http_x_forwarded_for"';

access_log  /var/log/nginx/access.log  main;

sendfile            on;
tcp_nopush          on;
tcp_nodelay         on;
keepalive_timeout   65;
types_hash_max_size 2048;
#proxy_cookie_path   ~*^/.* "~*^/.* HTTPOnly; Secure";

include             /etc/nginx/mime.types;
default_type        application/octet-stream;

include /etc/nginx/conf.d/*.conf;


vhost conf:

server {
listen       80;
rewrite ^ https://$http_host$request_uri? permanent;    # force redirect http to https

# Enables or disables emitting nginx version on error pages and in the "Server" response header field.
server_tokens off;

server {
listen 443 http2 ssl;
ssl on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;
ssl_dhparam   /etc/nginx/dhparam.pem;
ssl_prefer_server_ciphers  off;
ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;
ssl_session_tickets off;
add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains; preload';
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src 'none'; script-src blob: 'self' 'unsafe-inline' 'unsafe-eval' ; img-src 'self'; font-src data: 'self'; connect-src 'self'; style-src 'self' 'unsafe-inline'; frame-src; object-src 'none'; frame-ancestors; base-uri 'self'; media-src 'self';";
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Frame-Options sameorigin;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Permissions-Policy "geolocation=();midi=();notifications=();push=();sync-xhr=();microphone=();camera=();magnetometer=();gyroscope=();speaker=(self);vibrate=();fullscreen=(self);payment=();";
#add_header Referrer-Policy strict-origin-when-cross-origin;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/nginx/ssl/letsencrypt_ocsp.pem;
server_tokens off;

location / {
    proxy_pass    ;
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Host $server_name;
    proxy_set_header        X-Forwarded-Proto https;
    proxy_set_header        Cookie $http_cookie;
    access_log              /var/log/nginx/seahub.access.log;
    error_log               /var/log/nginx/seahub.error.log;
    proxy_read_timeout      1200s;

if ($request_method !~ ^(GET|DELETE|HEAD|POST|PUT)$ )
    return 405;

But my setup might be slightly different than yours, above is the config for a reverse proxy which is in front of another nginx proxy on the seafile side.
I hope this makes it clear:

NGINX Reverse Proxy <—> (HTTPS Traffic) Seafile Server with another NGINX before seahub

Hope it helps

1 Like

Hi @dan361, you’re right, once logged out, there is a loop (too many redirect) if we log in again. After remove the proxy_cookie_path, it works again :slight_smile:

Thank you so much for your share!

1 Like

I was able to get it working after cobbling together a fresh Nginx site file that includes the now famous

proxy_set_header        Cookie $http_cookie;

in the Seahub location (see @dan361 example above).

I was sadly not able to incorporate the now infamous

proxy_cookie_path   ~*^/.* "~*^/.* HTTPOnly; Secure";

anywhere in my configuration. Maybe someone will figure this out and pass along a solution.

Thank you @Miu and @dan361 for help with this problem.

Hello @mercury and @dan361: Does the options (share link, move, rename etc.) work with your configuration?

I meet the same “Permission denied” issue when I tried to use any of these options:


I only have one location in my Nginx where I configured the headers:

    location / {
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Host $server_name;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_set_header        Cookie $http_cookie;
        proxy_http_version 1.1;
        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;
        send_timeout  36000s;

        # used for view/edit office file via Office Online Server
        client_max_body_size 0;

        access_log      /var/log/nginx/seahub.access.log;
        error_log       /var/log/nginx/seahub.error.log;

Other location is related to seafhttp:

    location /seafhttp {
        rewrite ^/seafhttp(.*)$ $1 break;
        client_max_body_size 0;
        proxy_connect_timeout  36000s;
        proxy_read_timeout  36000s;
        proxy_send_timeout  36000s;
        send_timeout  36000s;
        proxy_request_buffering off;
        proxy_http_version 1.1;

As the 1st location include all the paths, I shouldn’t have any issue :confused:

Main difference is admin section does some PUT request on /api/v2.1/admin/web-settings/and file options like share does some POST request on /api/v2.1/share-links/

Thanks for your feedbacks :slight_smile:

Edit: Something strange for me… On my smartphone (Android), I can rename/delete/move, not with my browser on my workstation… I really don’t understand because it seems fine on a side (Android, but I can’t share), not on the other side (can’t share at all) … But this is the same server :sweat:

It sounds like you are having the same trouble I had initially. A couple things:

Your Seahub location (location / ) is the same as mine. I only added

proxy_set_header cookie $http_cookie;

but in my case


Do you require the IP address for your setup?

Otherwise, I had to clear browser cache with Nginx reloads when testing.

Hi @mercury, thanks for your feedbacks :slight_smile:

Think you have your reverse proxy on the same machine where is installed Seafile, that’s why you have proxy_pass;:slight_smile:

I’m happy it works for you! I did many different tests and I have the same results, I can’t get it to work whatever the situation:

  • Ubuntu 20.04/Generic Seafile v7.1.5 (and 8.0) <----> Nginx <----> Internet = KO
  • Ubuntu 20.04/Docker Seafile v7.1.5<----> Nginx <----> Internet = KO
  • Raspberry PI4 <----> Nginx <----> Internet = KO

Nginx seems to be the point to check but the config is pretty simple (except the Cookie option!).

@dan361seems to get it work with his config, but I can’t reproduced :frowning:

And it works with the Android application, which confusing me more because the Nginx configuration is the same.

I will do a new topic for this particular issue (as the Admin section works now!) and I will give up next an go with Syncthing, which just work… Very frustrating…

From your diagram do you have two instances of Nginx to contend with? Have you tried placing the

on the other (or both) Nginx proxy(s)?

Hi! Yes, I put the proxy_set_header everywhere I can :sweat_smile:

I if use the Docker setup, I have my own Nginx and the Nginx provided by the Seafile’s Docker. The proxy_set_header is set in both case.

If I use the generic Linux tar.gz, there is only my own Nginx (where the proxy_set_header is configured).

For both case, I have the permission denied. I’m pretty sure that it’s a Nginx configuration problem but i don’t find why…

What about the firewall? Is that a factor?

None active - and it worked under 7.1.5. Is there any change that needs to be done additionally when upgrading to 8.0.3 - especially since according to the changelog, the ccnet-service has been incorporated into the other parts?

Maybe this is old news and have been fixed long ago. But I’m sharing here what I did:

    add_header X-CSRFToken $cookie_sfcsrftoken always;

location / {
    add_header X-CSRFToken $cookie_sfcsrftoken always;
    proxy_set_header   Cookie $http_cookie;

location /seafhttp {
    add_header X-CSRFToken $cookie_sfcsrftoken always;
    proxy_set_header   Cookie $http_cookie;
    proxy_cookie_path   ~*^/.* "~*^/.* HTTPOnly; Secure; Samesite=lax";
1 Like