Miu
January 18, 2021, 5:11pm
1
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
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…
Thanks!
PS: I also tried without Docker, I installed Seafile in /opt
and I meet the same error message.
Miu
Edit: I saw the message from @mercury and just realize that I didn’t give the Seafile version
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
3.1.5
Miu
January 18, 2021, 7:48pm
3
Hey,
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.
dan361
January 18, 2021, 8:34pm
6
Hey,
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/nginx.pid;
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;
server_name seafile.mydomain.com;
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;
server_name seafile.mydomain.com;
ssl on;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_certificate /etc/letsencrypt/live/mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mydomain.com/privkey.pem;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
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 http://seafile.com/ https://www.seafile.com/ https://seafile.mydomain.com/ blob: 'self' 'unsafe-inline' 'unsafe-eval' ; img-src 'self'; font-src data: 'self'; connect-src 'self'; style-src 'self' 'unsafe-inline'; frame-src https://seafile.mydomain.com; object-src 'none'; frame-ancestors https://seafile.mydomain.com/; base-uri https://seafile.mydomain.com/ '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;
resolver 213.133.98.98;
location / {
proxy_pass https://seafback.mydomain.com;
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
Miu
January 18, 2021, 9:10pm
7
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
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.
Miu
January 19, 2021, 12:32pm
9
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_pass http://10.0.0.1:8000;
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;
proxy_pass http://10.0.0.1:8082;
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
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
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
mercury
January 19, 2021, 5:23pm
10
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
proxy_pass http://127.0.0.1:8000 ;
Do you require the IP address for your setup?
Otherwise, I had to clear browser cache with Nginx reloads when testing.
Miu
January 19, 2021, 7:34pm
11
Hi @mercury , thanks for your feedbacks
Think you have your reverse proxy on the same machine where is installed Seafile, that’s why you have proxy_pass http://127.0.0.1:8000;
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
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…
mercury
January 19, 2021, 7:53pm
12
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)?
Miu
January 22, 2021, 7:53am
13
Hi! Yes, I put the proxy_set_header
everywhere I can
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…
mercury
January 23, 2021, 5:29pm
14
What about the firewall? Is that a factor?
lars1
February 24, 2021, 6:23am
15
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:
server{
[...]
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