Unable to log into web interface since upgrade

[Larrikinau]

Thank you ever so much for the work you've put into upgrading us to Seafile CE 11.

It works and syncs fine with my clients.

When I go to my seafile instance website, I put in my username and password (correctly), and then this error message pops up:

Forbidden (403) CSRF verification failed. Request aborted. More information is available with DEBUG=True.

Any ideas on why that is happening? I can't go further so cannot access my seafile instance website anymore.

[ggogel]

Hi, thanks for the issue report.

Please try to clear your browser cache or try another browser.

Is there anything in the logs?

[Larrikinau]

I have a friend who is an expert and told me how to fix it. Unfortunately I can't provide any context as to how this fixed the problem, only that it did.

With the docker down, I had to edit the file seahub_settings.py

At the end of that file, I had to add the following line:

CSRF_TRUSTED_ORIGINS = ["https://myseafiledomain.com/"]

The myseafiledomain.com is replaced with my actual domain that I use to access seafile.

Started the docker, and boom, it fixed it.

No idea why as it's beyond my knowledge, and my friend is working at the moment and doesn't have the time to explain. Will try and find out more later.

[ggogel]

Glad you solved it!

For some reason, it works for me without that config on two different setups.

[mibuthu]

I had the same issue, also with a different browser.

The fix from Larrikinau worked but only with a small modification, I had to remove the trailing slash. So my working modification in seahub_settings.py is: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com']

[ggogel]

Thanks for reporting 👍

After reading the Django Documenation, it seems to me like your request is seen by Django as coming from a different server. The check also includes the correct protocol (HTTP or HTTPS).

Can you check if the SERVICE_URL shown in the System Admin settings of Seafile matches your URL, including HTTPS?

It could also be that the Origin header is set incorrectly somewhere in your reverse proxy setup.

[watn3y]

HI there :D

I'm having the same issue with a fresh deployment.

Here's the relevant part of my docker-compose file

    environment:
      - HTTPS=true
      - SEAFILE_SERVER_HOSTNAME=sea.watn3y.de 

After inspecting seahub_settings.py I can see that the protocol is not set to https everywhere.

SERVICE_URL = "http://sea.watn3y.de/"
...
FILE_SERVER_ROOT = "https://sea.watn3y.de/seafhttp"

Did I misunderstand the docs or is HTTPS=true not doing what it should?

[ggogel]

The environment variable HTTPS is only used for the intital deployment to construct the SERVICE_URL. Seafile then takes this value and writes it into the database. This value in the database takes precedence over the config file. You can only change it from the admin settings in the web UI or by overwriting the value in the database directly.

For the sake of coherence make sure that both values match and contain https.

[ggogel]

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL.

The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue https://github.com/haiwen/seafile/issues/2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues.

I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL.

If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py: Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.

2. Temporarily Adjust CSRF Settings: Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com'] Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.

3. Log in and Adjust Settings via Web UI: After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.

4. Revert CSRF Settings: Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

[lessbones]

I had this same issue yesterday, and I tried to fix it "literally adding the 's' to HTTPS in my SERVICE_URL" but I didn't realize at the time that my drive was completely 100% full. It gave me a warning about how it was truncating the file, and I foolishly saved my seahub_settings.py. Next time I opened it (after clearing some space) it was completely blank. I don't have a backup of that particular file and it seems to have nuked my system for now-- it couldn't have been more than 10-12 lines long-- can someone send me a template for what data was in this file, or should I try to re-run the setup-seafile-mysql.py script? Every example from the official seafile docker repo seems to contain much more information than I ever had in this file, so I feel like it's a different organizational system.

If all else fails I'll do a fresh install in a VM and try to figure out what I'm missing, but if anyone has a quick solution I'd appreciate it...

[ggogel]

You could create a second deployment, specifying a different project name with the parameter p. Then copy the file from there.

[lessbones]

thanks, i'll give that a shot--

[lessbones]

wow, i can't believe the extent of the havoc wreaked by the loss of this one file... I recreated it under a different name as you suggested, and I'm, able to use most of it, but then my db image was complaining about not being able to authenticate with the generated mysql user + pass. I've been migrating this system along for a long time, so I'm not sure if I have some older settings that are conflicting, but now when I alter seahub_settings.py to reflect what I think the proper mysql creds are (root/password) I can access the login screen of seafile, but it gives either the CSRF error or a generic "Page Unavailable" if I have the CSRF_TRUSTED_ORIGINS parameter filled in. I believe this is a database access error, but I'm having trouble figuring out which module I should focus my troubleshooting on. I don't remember ever having to enter this mariadb login information manually into seahub_settings.py before, but I don't understand why it generates with unusable login creds from my docker-compose.yml...

[ggogel]

When setting up Seafile for the first time, it executes a bootstrapping script for application and database configuration. During this process, Seafile utilizes the provided root credentials of the database to establish the necessary databases. It then creates a seafile user account, assigns it an auto-generated password, and records these details in the seahub_settings.py file.

Now there's a mismatch in these credentials. Use the root user to access the database. Update the seafile user's password to match the new value found in the seahub_settings.py.

Additionally, check for errors by executing docker logs on the seahub container.

Be aware that a full volume might have caused other file corruptions. To prevent such issues in the future, consider setting up a backup system.

[blaine07]

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL.

The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue haiwen/seafile#2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues.

I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL.

If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py: Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.
2. Temporarily Adjust CSRF Settings: Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com'] Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.
3. Log in and Adjust Settings via Web UI: After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.
4. Revert CSRF Settings: Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

These instructions seem pretty clear to me - but it's possible I am doing something wrong.

In Unraid, stopping Seafile, downloading seahub_settings.py file, making sure SERVICE URL is "https"(cloudflare reverse proxy/tunnel), removing the CSRF_TRUSTED_ORIGINS part, saving seahub_settings.py, uploadinb back to Unraid, setting file owner/permissions back to file and starting Seafile container.. Still get CSRF errors after triple checking in Settings that Service URL is "https" as well.

Not sure, but I can't seem to find any way around having the CSRF_TRUSTED_ORIGINS thing at moment on Seahub Instance that has already been installed, not a new install.

Any other ideas mate?

[blaine07]

I've dedicated some time to further investigate the issue. The bootstrap.py script included in this project relies on the environment variables HTTPS and SEAFILE_SERVER_HOSTNAME to construct the FILE_SERVER_ROOT configuration. However, this setup script does not configure the SERVICE_URL. The SERVICE_URL is actually configured by the setup-seafile-mysql.py script, which is bundled with Seafile. In this script, the http protocol is hard coded. Thus people using the official Docker deployment are reporting the same issue haiwen/seafile#2707. This discrepancy was inconsequential in older versions because Django did not enforce matching protocols. However, it now leads to these issues. I've implemented a workaround to address this issue for new deployments. The protocol is now set correctly in the SERVICE_URL. If you encounter login problems after upgrading, please follow these steps to resolve the issue:

1. Update SERVICE_URL in seahub_settings.py: Ensure the SERVICE_URL protocol is set correctly to reflect https or http as required by your deployment. While this value might be overlooked by Seafile, maintaining coherence in your configuration is beneficial.
2. Temporarily Adjust CSRF Settings: Add the following line to your seahub_settings.py: CSRF_TRUSTED_ORIGINS = ['https://myseafiledomain.com'] Replace https://myseafiledomain.com with your actual Seafile domain. Restart seahub to apply these changes.
3. Log in and Adjust Settings via Web UI: After successful login, go to the System Admin section of the web interface. Set the SERVICE_URL as above.
4. Revert CSRF Settings: Once the SERVICE_URL is correctly configured and functioning, remove the CSRF_TRUSTED_ORIGINS line from your seahub_settings.py. Restart the seahub service once more for the changes to take full effect.

These instructions seem pretty clear to me - but it's possible I am doing something wrong.

In Unraid, stopping Seafile, downloading seahub_settings.py file, making sure SERVICE URL is "https"(cloudflare reverse proxy/tunnel), removing the CSRF_TRUSTED_ORIGINS part, saving seahub_settings.py, uploadinb back to Unraid, setting file owner/permissions back to file and starting Seafile container.. Still get CSRF errors after triple checking in Settings that Service URL is "https" as well.

Not sure, but I can't seem to find any way around having the CSRF_TRUSTED_ORIGINS thing at moment on Seahub Instance that has already been installed, not a new install.

Any other ideas mate?

Still unable to get this to work without the trusted origins modifcation to settings py file. No idea what I am doing wrong or if something relative to that the container is running in docker on Unraid. Not sure; but would like to fix this correctly. :-(

[ggogel]

I've just seen your comment here https://github.com/haiwen/seafile/issues/2707#issuecomment-1818704949

Try to replace

proxy_set_header X-Forwarded-Proto $scheme;

with

proxy_set_header X-Forwarded-Proto https;

In your nginx config it seems like it is listening to port 80. So if you are using https, there must be another reverse proxy in front of it listening to port 443, which then proxies to this nginx.

If you require further assistance, please detail your network setup, specifically in regard to which proxies are traversed when accessing your Seafile setup.

[ggogel]

At a closer look, you also have /location seafhttp in your nginx config. Are you using nginx instead of the seafile-caddy provided here? I can't really make sense of your config at the moment.

[blaine07]

I've just seen your comment here haiwen/seafile#2707 (comment)

Try to replace

proxy_set_header X-Forwarded-Proto $scheme;

with

proxy_set_header X-Forwarded-Proto https;

In your nginx config it seems like it is listening to port 80. So if you are using https, there must be another reverse proxy in front of it listening to port 443, which then proxies to this nginx.

If you require further assistance, please detail your network setup, specifically in regard to which proxies are traversed when accessing your Seafile setup.

This worked; changing "proxy_set_header X-Forwarded-Proto https;" in the nginx config for Seafile.

FWIW - I have Seafile running in a container on Unraid. I have a Cloudflare Tunnel/proxy instance handling reverse proxy running on same Unraid Server pointing to Seafile outside>in.

In the future will I ever need to do this again; will the "https" change forever stick?

ALSO -- THANK YOU!! :-) Now this is configured right/safe and I feel much better. Thanks.

[lessbones]

I still haven't been able to solve my main issue (I seem to have corrected the mariadb passwords where necessary, but my seafile server container is also constantly trying to "update" to version 1.x.x and throwing an error about not finding python 2.6...)

But my main issue now is that if I set up a new instance with "-p" I can't get rid of the CSRF error no matter what-- I'm thinking now that this is likely because I'm using Traefik as a reverse proxy? I don't really need to be any more, so I can get rid of that, but it is kind of nice to have if I decide to host anything else in the future...

[ggogel]

I still haven't been able to solve my main issue (I seem to have corrected the mariadb passwords where necessary, but my seafile server container is also constantly trying to "update" to version 1.x.x and throwing an error about not finding python 2.6...)

How and what exactly is trying to update to version 1.x.x? The current Seafile version is 11. Can you please provide some logs?

But my main issue now is that if I set up a new instance with "-p" I can't get rid of the CSRF error no matter what-- I'm thinking now that this is likely because I'm using Traefik as a reverse proxy? I don't really need to be any more, so I can get rid of that, but it is kind of nice to have if I decide to host anything else in the future...

I've worked a couple of times with Traefik and always had problems with it. It has a ton of bugs and awful documentation. I'd recommend you use one of these reverse proxies https://github.com/ggogel/seafile-containerized/wiki/Reverse-Proxy#reverse-proxy

[lessbones]

sorry for the slow responses. I don't really believe that this has anything to do with the issue with traefik (if that indeed is the issue). I kinda hate traefik too, but once I got it set up ages ago it did work well, although these days I don't have any need for a reverse proxy at the moment, so the first thing I'll do is try ditching it. Again, this issue doesn't happen if I start a new instance using "-p" but my logs in the original instance for seafile-server are as follows:

Seafile-Server Logs

docker logs 22e418b0299d Waiting for SeaRPC socket... [2023-12-12 20:57:06] Skip running setup-seafile-mysql.py because there is existing seafile-data folder. [2023-12-12 20:57:06] Running scripts /opt/seafile/seafile-server-11.0.2/upgrade/upgrade_1.2_1.3.sh ------------------------------ Fix seafevents conf success ------------------------------ [12/12/2023 20:57:06][upgrade]: Running script /opt/seafile/seafile-server-11.0.2/upgrade/upgrade_1.2_1.3.sh ------------------------------------------------------------- This script would upgrade your seafile server from 1.2.0 to 1.3.0 Press [ENTER] to contiune ------------------------------------------------------------- Can't find a python executable of version 2.6 or above in PATH Install python 2.6+ before continue. Or if you installed it in a non-standard PATH, set the PYTHON enviroment variable to it Traceback (most recent call last): File "/scripts/start.py", line 66, in main() File "/scripts/start.py", line 52, in main check_upgrade() File "/scripts/upgrade.py", line 182, in check_upgrade run_script_and_update_version_stamp(script, new_version) File "/scripts/upgrade.py", line 61, in run_script_and_update_version_stamp call(script) File "/scripts/utils/__init__.py", line 70, in call return subprocess.check_call(*a, **kw) File "/usr/lib/python3.10/subprocess.py", line 369, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command '/opt/seafile/seafile-server-11.0.2/upgrade/upgrade_1.2_1.3.sh' returned non-zero exit status 1.`

I can't figure out where it's getting the info that my server is that low of a version.

as far as seahub it's looking like this:

Seahub-Logs

LC_ALL is not set in ENV, set to en_US.UTF-8 Starting seahub at port 8000 ... Error happened during creating seafile admin. Seahub is not running Done. 2023-12-12 20:57:10,382 [INFO] seafevents.db:62 create_engine_from_conf [seafevents] database: mysql, name: seahub_db 2023-12-12 20:57:10,382 [INFO] seafevents.db:62 create_engine_from_conf [seafevents] database: mysql, name: seahub_db Seahub is started Done.

and mariadb

mariadb-logs

`2023-12-13 01:57:05+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.2.2+maria~ubu2204 started. 2023-12-13 01:57:06+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2023-12-13 01:57:06+00:00 [Note] [Entrypoint]: Entrypoint script for MariaDB Server 1:11.2.2+maria~ubu2204 started. 2023-12-13 01:57:06+00:00 [Note] [Entrypoint]: MariaDB upgrade information missing, assuming required 2023-12-13 01:57:06+00:00 [Note] [Entrypoint]: MariaDB upgrade (mariadb-upgrade) required, but skipped due to $MARIADB_AUTO_UPGRADE setting 2023-12-13 1:57:06 0 [Note] Starting MariaDB 11.2.2-MariaDB-1:11.2.2+maria~ubu2204 source revision 929532a9426d085111c24c63de9c23cc54382259 as process 1 2023-12-13 1:57:06 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2023-12-13 1:57:06 0 [Note] InnoDB: Number of transaction pools: 1 2023-12-13 1:57:06 0 [Note] InnoDB: Using crc32 + pclmulqdq instructions 2023-12-13 1:57:06 0 [Note] mariadbd: O_TMPFILE is not supported on /tmp (disabling future attempts) 2023-12-13 1:57:06 0 [Note] InnoDB: Using liburing 2023-12-13 1:57:06 0 [Note] InnoDB: Initializing buffer pool, total size = 128.000MiB, chunk size = 2.000MiB 2023-12-13 1:57:06 0 [Note] InnoDB: Completed initialization of buffer pool 2023-12-13 1:57:06 0 [Note] InnoDB: Resetting space id's in the doublewrite buffer 2023-12-13 1:57:06 0 [Note] InnoDB: File system buffers for log disabled (block size=512 bytes) 2023-12-13 1:57:06 0 [Note] InnoDB: End of log at LSN=394833812 2023-12-13 1:57:06 0 [Note] InnoDB: Opened 3 undo tablespaces 2023-12-13 1:57:06 0 [Note] InnoDB: 128 rollback segments in 3 undo tablespaces are active. 2023-12-13 1:57:06 0 [Note] InnoDB: Setting file './ibtmp1' size to 12.000MiB. Physically writing the file full; Please wait ... 2023-12-13 1:57:06 0 [Note] InnoDB: File './ibtmp1' size is now 12.000MiB. 2023-12-13 1:57:06 0 [Note] InnoDB: log sequence number 394833812; transaction id 2784241 2023-12-13 1:57:06 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2023-12-13 1:57:06 0 [Note] Plugin 'FEEDBACK' is disabled. 2023-12-13 1:57:06 0 [Note] Plugin 'wsrep-provider' is disabled. 2023-12-13 1:57:06 0 [Note] Server socket created on IP: '0.0.0.0'. 2023-12-13 1:57:06 0 [Note] Server socket created on IP: '::'. 2023-12-13 1:57:06 0 [Warning] 'proxies_priv' entry '@% root@d2948c30ce73' ignored in --skip-name-resolve mode. 2023-12-13 1:57:06 0 [Note] mariadbd: Event Scheduler: Loaded 0 events 2023-12-13 1:57:06 0 [Note] mariadbd: ready for connections. Version: '11.2.2-MariaDB-1:11.2.2+maria~ubu2204' socket: '/run/mysqld/mysqld.sock' port: 3306 mariadb.org binary distribution 2023-12-13 1:57:06 3 [Warning] Aborted connection 3 to db: 'unconnected' user: 'root' host: '192.168.112.5' (Got an error reading communication packets) 2023-12-13 1:57:07 0 [Note] InnoDB: Buffer pool(s) load completed at 231213 1:57:07`

[ggogel]

It is reading the version in this method:

https://github.com/ggogel/seafile-containerized/blob/37a7a6a9a335158d101d7ff7aea0952f7bb08e7d/seafile-server/scripts/utils/__init__.py#L257

Connecting to the container using docker exec:

cat /shared/seafile/seafile-data/current_version
11.0.3

Probably, the file got deleted during the upgrade, and then it couldn't be recreated because the disk was full.

I would suggest you create this file and set the version to whatever you had before your instance failed.

Just be aware that more and more problems like this could start coming up due to the full disk issue. So it might be easier to start from scratch and upload your files again.

[lessbones]

thanks for that-- i'll see if that gets me any further. The drive is no longer full by any means-- I've been trying to recreate the whole thing from scratch using -p and now i'm just constantly getting issues with not being able to log in with the user/pass in the docker-compose file- and this is after "system purge -a" So there are a lot of issues I'm currently up against for one reason or another. I don't need to keep the files on this system, it's designed to be a temporary client file transfer anyway, so I don't even care if I have to start from scratch, but I also have some other work to do with changing subdomain forwarding. I already removed traefik from the equation, so i'm just testing with a local ip address, but I haven't taken the time to go into the mariadb container and attempt to reset the admin password manually after the "error creating seafile admin" it's reporting in the logs.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[moritzj29]

I faced this issue today with a fresh install. Apparently, in the generated seahub_settings.py the SERVICE_URL contains a trailing slash which causes the CSRF error:

https://seafile.example.com/ vs. https://seafile.example.com

I guess this is the relevant line in the original repo:

https://github.com/haiwen/seafile-docker/blob/efff562342036212bee746aa203b152ee0bf9420/scripts/scripts_11.0/setup-seafile-mysql.py#L1048

Following the steps above, I was able to override the CSRF check, fix the config and put the check back in place. Thanks!