Migrating CE server to docker - a few issues

Trying to migrate my install of Seafile server 12.0.14 into docker
(docker is there and already running acouple of other containers)

first (of a few) hurdles i’ve struck is a permissions error - can’t seem to get the container to run.

I have installed the docker container and modified the .env file based on here

I have restored the databases based on here

I think I have mounted the seafile-data folder correctly (via a mnt in fstab), I can see files in the mounted folder ok

Based on this thread…

I have modifed the seafile-server.yml and added a map which looks like this

volumes:

- ${SEAFILE_VOLUME:-/opt/seafile-data}:/shared

- /mnt/SFData/:/shared/seafile/seafile-data
environment:

However, Bringing the container up seems to be ok, but logs show problems on startup

bunny@bunny-pc:/opt/seafile$ docker compose up -d
[+] up 5/5
 ✔ Container seafile-memcached Running                                      0.0s
 ✔ Container seafile-mysql     Healthy                                      0.5s
 ✔ Container seafile-caddy     Running                                      0.0s
 ✔ Container seadoc            Running                                      0.0s
 ✔ Container seafile           Running                       
 bunny@bunny-pc:/opt/seafile$ docker logs seafile -f
*** Running /etc/my_init.d/01_create_data_links.sh...
*** Booting runit daemon...
*** Runit started as PID 21
*** Running /scripts/enterpoint.sh...
2026-02-12 16:35:55 Waiting Nginx 
2026-02-12 16:35:55 Nginx ready 
2026-02-12 16:35:55 This is an idle script (infinite loop) to keep container running. 
[2026-02-12 16:35:56] Skip running setup-seafile-mysql.py because there is existing seafile-data folder.
[02/12/2026 16:35:56][upgrade]: The container was recreated, start fix the media symlinks
mv: not replacing '/shared/seafile/seahub-data/avatars/default-non-register.jpg'
mv: not replacing '/shared/seafile/seahub-data/avatars/default.png'
mv: not replacing '/shared/seafile/seahub-data/avatars/groups'
[02/12/2026 16:35:56][upgrade]: Done

Error: the user running the script ("root") is not the owner of "/shared/seafile/seafile-data" folder, you should use the user "ubuntu" to run the script.
Traceback (most recent call last):
  File "/scripts/start.py", line 94, in <module>
    main()
  File "/scripts/start.py", line 79, in main
    call('{} start'.format(get_script('seafile.sh')))
  File "/scripts/utils.py", line 70, in call
    return subprocess.check_call(*a, **kw)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/subprocess.py", line 413, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '/opt/seafile/seafile-server-12.0.14/seafile.sh start' returned non-zero exit status 255.

Main questions are

  1. Doesn’t look like Seahub is even getting started, how to deal with this root/owner problem on startup?
  2. The /opt/seafile-data/seafile folder is mostly red Xs except for logs/seahub-data - seafile-data folder can’t be accessed, except via sudo terminal. There is data in it so do I just delete all this and mount my /mnt/SFData folder in its place?
    This post suggests mounting my data folder over top of the existing folder, I assume by modifying the fstab file
    Reddit - The heart of the internet
  3. On the setup page for CE it says “From Seafile Docker 12.0, we use the Caddy to do web service proxy.”
    I have a apache webserver vhost running that acts as the proxy - using proxypass/reverse etc, is caddy still needed in this instance?
  4. Are there any other configurations/files I might need to update the new installation with from the old installation, or is it all in the main data folder /opt/seafile-data/seafile/seafile-data folder now? and this will all work properly when SFData is mounted correctly?

Sorry for the long rambling post…

It looks like you’re encountering some common hurdles during this process. Let’s break down each point and provide some solutions.

1. Root/Owner Permission Problem on Startup (Seahub not starting)

The error message Error: the user running the script ("root") is not the owner of "/shared/seafile/seafile-data" folder, you should use the user "ubuntu" to run the script. is a bit misleading here. For Seafile Docker version 12.0+, the container generally runs as the root user by default. The problem is that the root user inside the container doesn’t have the necessary permissions to access or modify the mounted seafile-data directory on your host.

To resolve this, you need to ensure the host directory mounted to /shared/seafile/seafile-data (or /shared if it contains seafile/seafile-data) is owned by root and has appropriate permissions.

Steps to resolve:

  1. Stop your Docker containers:
    docker compose down
    
  2. Ensure NON_ROOT=true is not present in your .env file, as it’s not applicable for the default root user setup in Docker 12.0+.
  3. Adjust ownership and permissions for your Seafile data directory on the host. If your SEAFILE_VOLUME in .env points to /opt/seafile-data/, or if /mnt/SFData/ is your actual data directory:
    sudo chown -R root:root /mnt/SFData/ # Use the correct path for your seafile-data on the host
    sudo chmod -R 770 /mnt/SFData/ # Provides read/write/execute for owner and group, no access for others.
    
    Replace /mnt/SFData/ with the actual path to your seafile-data directory on your host system.
  4. Start Seafile again:
    docker compose up -d
    

2. /opt/seafile-data/seafile folder access and mounting

Your seafile-server.yml shows a potential conflict with two volume mounts:

volumes:
  - ${SEAFILE_VOLUME:-/opt/seafile-data}:/shared
  - /mnt/SFData/:/shared/seafile/seafile-data

Seafile expects its data directory structure (including seafile-data) to reside directly under the /shared mount point within the container. Having two overlapping or conflicting mounts can lead to unexpected behavior.

Points to check and actions:

  1. Clarify your SEAFILE_VOLUME: In your .env file, ensure SEAFILE_VOLUME is set to the absolute path on your host where your primary seafile-data directory is located (e.g., SEAFILE_VOLUME=/mnt/SFData).
  2. Simplify seafile-server.yml: With SEAFILE_VOLUME correctly defined in your .env file, your seafile-server.yml should ideally have only one volume mount that maps this entire volume to /shared:
    volumes:
      - ${SEAFILE_VOLUME}:/shared
    
    This means that whatever is at ${SEAFILE_VOLUME} on your host will appear as /shared inside the container.

3. Caddy vs. Apache for Web Service Proxy

While Seafile Docker 12.0+ indeed ships with and recommends Caddy as the web service proxy for ease of setup, you are correct that you do not need to run Caddy if you are already using Apache as a reverse proxy. You can continue to use your existing Apache web server for this purpose.

In this scenario, you would configure your Apache vhost to reverse proxy requests directly to the Seafile container’s internal web server (on 80 port). You would then remove or comment out the Caddy service from your docker-compose.yml file. The Seafile manual provides documentation on using other reverse proxies, which can be adapted for Apache configurations .

4. Other Configurations/Files for Migration

Most essential configurations for Seafile itself (like seahub_settings.py, seafile.conf, etc.) are typically stored within the seafile-data directory. If your database restoration is successful and the seafile-data directory is correctly mounted and has the appropriate root ownership and permissions, then the majority of your primary data and configurations should be carried over. The .env file handles Docker-specific environment variables.

Here is a more clear answer that I generated with AI and double checked, hope this help.

Here is a breakdown of your questions and how you can resolve them.

1. Root/Owner Permission Problem on Startup

The error message Error: the user running the script ("root") is not the owner of "/shared/seafile/seafile-data" folder... is a known point of confusion. In Seafile Docker 12.0+, the container runs as the root user. The problem is that the root user inside the container doesn’t have permission to write to the data directory you’ve mounted from your host.

Solution: You need to change the ownership of your data directory on the host machine to root.

  1. First, bring down your containers:
    docker compose down
    
  2. Next, change the ownership and permissions of your seafile-data directory on the host. Replace /mnt/SFData/ with the actual path to your data.
    sudo chown -R root:root /mnt/SFData/
    sudo chmod -R 770 /mnt/SFData/
    
  3. Now, start the containers again:
    docker compose up -d
    

2. Folder Access and Volume Mounting

Your seafile-server.yml file has a conflicting volume configuration. You are mounting a main volume to /shared and then immediately trying to mount another volume over a subdirectory inside it. This can cause unpredictable behavior.

Solution: Simplify your volume mounts.

  1. In your .env file, make sure SEAFILE_VOLUME is set to the absolute path of your data directory on the host. For example:
    SEAFILE_VOLUME=/mnt/SFData
    
  2. Then, update the volumes section in your seafile-server.yml to have only one entry for the Seafile data. This will map your host directory directly to /shared in the container.
    volumes:
      - ${SEAFILE_VOLUME}:/shared
    

3. Caddy vs. Apache for Web Proxy

You are correct. Since you already have a working Apache reverse proxy, you do not need to use the Caddy container. Caddy is included for convenience in new setups.

Solution:

  1. You can safely comment out or remove the caddy service from your docker-compose.yml (or seafile-server.yml).
  2. Configure your Apache vhost to proxy requests to the Seafile container’s internal web server, which runs on port 80.

4. Other Configurations for Migration

The most critical parts of the migration are the SQL databases and the seafile-data directory. The seafile-data directory contains all your libraries and important configuration files (seafile.conf, seahub_settings.py, etc.).

If you have restored the databases and correctly mounted the seafile-data directory (with the right permissions), most of your setup should carry over.

For a comprehensive guide, it is highly recommended to follow the official documentation on migrating from a non-Docker to a Docker deployment. This will ensure you don’t miss any steps.

Official Guide: Migrate from non-docker deployment - Seafile Admin Manual

Hope this helps you get your Docker setup running smoothly!

Thanks for all the help - making progress…

For Question 1 - I was able to resolve by modifying the fstab entry mounting directly to /opt/seafile-data/seafile/seafile-data and setting uid=0,gid=0 for root…

//nas.local/_myData$ /opt/seafile-data/seafile/seafile-data cifs uid=0,gid=0,file_mode=0755,dir_mode=0755,credentials=/etc/credential 0 0

This mounts the folder in place of local folder. Which also negated the need for extra line in seafile-server.yml (The issue in Question 2) ie the extra line below ${SEAFILE_VOLUME:-/opt/seafile-data}:/shared - removed that and now seafile appears to start ok

** Running /etc/my_init.d/01_create_data_links.sh…*** Booting runit daemon…*** Runit started as PID 21*** Running /scripts/enterpoint.sh…2026-02-13 08:35:39 Waiting Nginx2026-02-13 08:35:39 Nginx ready2026-02-13 08:35:39 This is an idle script (infinite loop) to keep container running.[2026-02-13 08:35:39] Skip running setup-seafile-mysql.py because there is existing seafile-data folder.[02/13/2026 08:35:39][upgrade]: The container was recreated, start fix the media symlinksmv: not replacing ‘/shared/seafile/seahub-data/avatars/default-non-register.jpg’mv: not replacing ‘/shared/seafile/seahub-data/avatars/default.png’mv: not replacing ‘/shared/seafile/seahub-data/avatars/groups’[02/13/2026 08:35:39][upgrade]: Done

Starting seafile server, please wait …Seafile server started

Done.

Starting seahub at port 8000 …

Seahub is started

Done.

UPDATE - figured out it needed port mapping of “8000:80” which got me to the sign in screen, then a CSRF error, which I’ve sorted by adding domain entry to CSRF_TRUSTED_ORIGIN in seahub_settings.py

Next stage is working out why my login credentials aren’t working…

I’ll leave the rest in case it still needed

******

So, that leaves Question 3 about caddy and vhosts etc have removed references to caddy in seafile-server.yml label: and I have removed/commented out the 3 references to caddy in the /opt/seafile/.env file

as it is the docker container starts but I cannot access the web interface for it

My vhosts file from apache may need changing?

Alias /media  /opt/seafile/seafile-server-latest/seahub/media
    <Location /media>
        Require all granted
    </Location>

    # seafile fileserver  - OLD IP 234 / NEW IP 221
    ProxyPass /seafhttp http://192.168.20.221:8082
    ProxyPassReverse /seafhttp http://192.168.20.221:8082
    RewriteEngine On
    RewriteRule ^/seafhttp - [QSA,L]

    # seahub web interface
    SetEnvIf Authorization "(.*)" HTTP_AUTHORIZATION=$1
    ProxyPass / http://192.168.20.221:8000/
    ProxyPassReverse / http://192.168.20.221:8000/
    
#NEVER GOT THIS BIT WORKING...
    #<Location /seafdav>
    #    #Require all granted
	#	RequestHeader set "X-Forwarded-Proto" expr=%{REQUEST_SCHEME}
	#	RequestHeader set "X-Forwarded-SSL" expr=%{HTTPS}
	#	ProxyPass  http://192.168.20.221:8080/seafdav
	#	ProxyPassReverse  http://192.168.20.221:8080/seafdav
   # </Location>

is that /media path still going to be accurate? the seafile-server-latest folder doesn’t appear to feature in the new systems file paths?

and port numbers are still the same? they need to be added to seafile-server-yml?

80 and 8080 are giving errors on startup, hence hashed - I know what 8080 is (another webui), best way to change that is?

    ports:
      #- "80:80"
      - "8000:8000"
      #- "8080:8080"
      - "8082:8082"

Not sure about port 80, it appears to be seadoc-server?

bunny@bunny-pc:/opt/seafile$ docker ps -a
CONTAINER ID   IMAGE                               COMMAND                  CREATED         STATUS                   PORTS                                                                                                                               NAMES
9422928b7766   seafileltd/sdoc-server:1.0-latest   "/sbin/my_init -- /s…"   8 minutes ago   Up 8 minutes             80/tcp                                                                                                                              seadoc
9904d335cd3a   seafileltd/seafile-mc:12.0-latest   "/sbin/my_init -- /s…"   8 minutes ago   Up 8 minutes             0.0.0.0:8000->8000/tcp, [::]:8000->8000/tcp, 80/tcp, 0.0.0.0:8082->8082/tcp, [::]:8082->8082/tcp                                    seafile
3c13159b8193   memcached:1.6.29                    "memcached -m 256"       8 minutes ago   Up 8 minutes             11211/tcp                                                                                                                           seafile-memcached
735da8b79e64   mariadb:10.11                       "docker-entrypoint.s…"   8 minutes ago   Up 8 minutes (healthy)   3306/tcp                                                                                                                            seafile-mysql
10c17bb7465c   cooolin/socks5                      "/socks5"                2 weeks ago     Up 11 hours                                                                                                                                                  socks5-cooolin
dcb24f56f9f6   qmcgaw/gluetun                      "/gluetun-entrypoint"    2 weeks ago     Up 11 hours (healthy)    8000/tcp, 0.0.0.0:1080->1080/tcp, [::]:1080->1080/tcp, 0.0.0.0:8888->8888/tcp, [::]:8888->8888/tcp, 8388/tcp, 8388/udp              gluetun
90b08d6c7e81   storjlabs/storagenode:latest        "/entrypoint"            3 weeks ago     Up 11 hours              192.168.20.221:14002->14002/tcp, 0.0.0.0:28967->28967/tcp, 0.0.0.0:28967->28967/udp, [::]:28967->28967/tcp, [::]:28967->28967/udp   storagenode

When I access the site i get this, which suggests not getting past the Apache virtual host (Win64), seafile and docker are on Ubuntu…

Service Unavailable

The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.53 (Win64) OpenSSL/1.1.1n PHP/7.4.32 Server at sf.tct.dynu.com Port 443

Apache logs give me this

[Fri Feb 13 15:33:55.100928 2026] [proxy:error] [pid 7960:tid 3268] (OS 10061)No connection could be made because the target machine actively refused it.  : AH00957: http: attempt to connect to 192.168.20.221:8000 (192.168.20.221) failed

[Fri Feb 13 15:33:55.100928 2026] [proxy_http:error] [pid 7960:tid 3268] [client w.x.y.z:28601] AH01114: HTTP: failed to make connection to backend: 192.168.20.221

Thanks for reading - any help appreciated …

Next problem…

Now I have pretty much a clean install, had to run admin password reset script to get access, no libraries nothing…

I can get logged in but it is basically a clean installation - none of my data is there

thought maybe I didn’t restore the databases so did so again as such

docker cp /opt/seafile-data/seafile/seafile-data/backup/databases/ccnet_db.sql seafile-mysql:/tmp/ccnet_db.sql
docker cp /opt/seafile-data/seafile/seafile-data/backup/databases/seafile_db.sql seafile-mysql:/tmp/seafile_db.sql
docker cp /opt/seafile-data/seafile/seafile-data/backup/databases/seahub_db.sql seafile-mysql:/tmp/seahub_db.sql

docker exec -it seafile-mysql /bin/sh -c "mariadb --user=root --password ccnet_db < /tmp/ccnet_db.sql"
docker exec -it seafile-mysql /bin/sh -c "mariadb --user=root --password seafile_db < /tmp/seafile_db.sql"
docker exec -it seafile-mysql /bin/sh -c "mariadb --user=root --password seahub_db < /tmp/seahub_db.sql"

then tried again, still no go - just a clean install…

Exported the database again just to make sure something is there - this gave me a shiny new file 8.6MB, which matches the source file. same with the other two databases

docker exec seafile-mysql mariadb-dump --host=localhost --user=root --password=XXXXXXX --lock-tables --databases seahubdb > /opt/seafile-data/seafile/seafile-data/backup/databases/seahubdb.sql.`date +"%Y-%m-%d-%H-%M-%S"`

so really pleased that it is up and running, just need a little more guidance on how to progress…

Should I maybe try another complete backup of the data folder and databases and try restoring them again?

ANOTHER UPDATE: looking at this again just now I seem to be getting my database names mixed up, the most recent export was from seahubdb? not seahub_db? I exported seahub_db and it was tiny - I guess that explains it -

The original server did use seahubdb etc as DB names, would that be hard coded into the SQL backup somehow, might explain it or me just getting careless with where i dump stuff.

Would it be easier to just change the DB names seafile is accessing, is that in the .env file now?

I’ll have another look at this tomorrow…

There are environtment variables for setting DB names.

Regarding port, Seafile docker image has a built-in Nginx listen on port 80. This Nginx forward requests to the correct components within the docker image.

I suggest you not to use seadoc-server during setting up. It makes things simple.

When the main service seafile works okay, you can then try to setup seadoc-server if you want to use the sdoc extension.

thanks for the reply Daniel, the environment variables was what I was looking for

Could you also have a look at my directory structure please - it seems a bit funky as well

Top Level of Seafile-data

Seafile folder - inside this image below is the seafile-data folder mounted via fstab from my other install…

My actual seafile-data folder

This storage folder above contains my blocks, commits and fs folders

I’m seeing similarities between the first and last images which makes me think i may be mounting it in the wrong place.

As it is when i activate my correct databases two things happen

  1. I get “Error happened during creating seafile admin.” in the docker logs seafile -f
  2. I get to the login screen but as soon as I sign in I get an error
 Page unavailable

Sorry, but the requested page is unavailable due to a server hiccup.

Our engineers have been notified, so check back later.”

The suggestion way to Migrating from non-docker version to docker version is following this document: Migrate from non-docker deployment - Seafile Admin Manual

First you setup a running new Docker based deployment. Then you restore MySQL database and then copy the older contents in seafile-data to the new seafile-data.

Note, there are two levels of seafile-data that causing confusing. The first level seafile-data is for mount into the docker container (it can be renamed to seafile-volumn to avoid confusing). This is the folder shown in your first screenshot.

The second level seafile-data is under /opt/seafile-data/seafile/seafile-data. It contains only seafile commits/fs/blocks.

In you binary setup, if you deploy it under /opt/seafile. You directory looks like:

In docker based setup, if you deploy it under /opt/seafile-data. You directory looks like:

/opt/seafile-data (This can be better called seafile-volumn)
    -- seafile
    -- logs

Look, you should copy the contents under “/opt/seafile” in binary setup to “/opt/seafile-data/seafile” in docker setup.

In summary, you should focus on the seafile folder that contains seafile-data, configuration folder and other things. Not the second level seafile-data, which only contains commits/fs/blocks.

Be sure to copy all contents of /opt/seafile (binary setup) to /opt/seafile-data/seafile (docker based setup).

thanks Daniel I will check that, I also see a bunch of errors in the seafile.log

[2026-02-14 14:51:11] [WARNING] ../common/seaf-db.c(867): Failed to connect to MySQL: Access denied for user 'seafile'@'%' to database 'seafiledb'
[2026-02-14 14:51:13] [WARNING] ../common/seaf-db.c(867): Failed to connect to MySQL: Access denied for user 'seafile'@'%' to database 'seafiledb'
[2026-02-14 14:51:13] [WARNING] http-server.c(901): DB error when check repo existence.
[2026-02-14 14:51:14] [WARNING] ../common/seaf-db.c(867): Failed to connect to MySQL: Access denied for user 'seafile'@'%' to database 'ccnetdb'
[2026-02-14 14:51:14] [WARNING] ../common/seaf-db.c(867): Failed to connect to MySQL: Access denied for user 'seafile'@'%' to database 'ccnetdb'

is that consistent with this or another problem

This is a database access permission error. You should fix it first.

appreciate your help Daniel but I seem to be going backwards now… I copied all those files and folders over, checking them and adjusting the mysql passwords in several places (which I made a bit stronger for the docker install… ) , now on docker up all I get is this from the log and Bad Gateway from web page.

*** Running /etc/my_init.d/01_create_data_links.sh...
*** Booting runit daemon...
*** Runit started as PID 21
*** Running /scripts/enterpoint.sh...
2026-02-14 16:35:43 Waiting Nginx 
2026-02-14 16:35:43 Nginx ready 
2026-02-14 16:35:43 This is an idle script (infinite loop) to keep container running. 
waiting for mysql server to be ready: mysql is not ready
waiting for mysql server to be ready: mysql is not ready
waiting for mysql server to be ready: mysql is not ready
waiting for mysql server to be ready: mysql is not ready
waiting for mysql server to be ready: mysql is not ready
waiting for mysql server to be ready: mysql is not ready

Database schema

MariaDB [(none)]> SELECT table_schema AS "Database", 
    -> ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS "Size (MB)" 
    -> FROM information_schema.TABLES 
    -> GROUP BY table_schema;
+--------------------+-----------+
| Database           | Size (MB) |
+--------------------+-----------+
| ccnetdb            |      0.42 |
| ccnet_db           |      0.42 |
| information_schema |      0.20 |
| mysql              |     12.41 |
| performance_schema |      0.00 |
| seafiledb          |      1.70 |
| seafile_db         |      1.50 |
| seahubdb           |     20.36 |
| seahub_db          |      5.48 |
| sys                |      0.03 |
+--------------------+-----------+
10 rows in set (0.163 sec)

tried several times but I just cannot get the actual data to import into the *_db databases. But given the environment vars in the env file it shouldn’t matter

Nothing is now being written to the seafile and seahub logs, so I guess we are waiting for the DB to start up first…

any hope for this installation or should I scrap it and start again

so started again from the beginning, up and running now on docker - yay!.

My problems mostly seem to be from the non-standard database names used in the previous install. Once I decided to use the default database names things started working correctly.

A few notes on this for the record…

When exporting databases from non-default database names (ie NOT ccnet_db, seafile_db, seahub_db), when importing the sql, the database will be created with the same non-default name.

The databases are referenced in seahub_settings.py, seafevents.conf, seafile.conf as far as I can tell, but changing these still wouldn’t get it up and running. Adding environment vars into the .env file for the database names did not seem to help. I was running into issues ( from the mysql log) with the MYSQL user ‘seafile’ not having permissions to access the newly created, non-standard named, databases. Tried granting access but couldn’t get it work…

In the end I opted to use the default names but you need to edit the database name to the default value (ccnet_db etc) within each of the sql files (four places in each).

When transitioning from binary to docker the above settings files also need to have the ‘host’ value changed from 127.0.0.1 to ‘db’, which probably explains the ‘waiting for mysql server to be ready: mysql is not ready” error I was having at one point

There were a couple of entries in the config on docker, not present in my binary version (both 12.0.14) - These need to be added to your existing (binary) configs, for me at least…

gunicorn.conf.py

# for forwarder headers
forwarder_headers = 'SCRIPT_NAME,PATH_INFO,REMOTE_USER'

seahub_settings.py (dont think I was using memcache)

CACHES = {
    'default': {
        'BACKEND': 'django_pylibmc.memcached.PyLibMCCache',
        'LOCATION': 'memcached:11211',
    },
    'locmem': {
        'BACKEND': 'django.core.cache.backends.locmem.LocMemCache',
    },
}
COMPRESS_CACHE_BACKEND = 'locmem'

and in seahub_settings.py - # Mentioned this because it’s the first error I got when trying to signin.

CSRF_TRUSTED_ORIGINS = ["https://your.domain.com"]

HTH someone…

I do have one minor problem post install, the password reset emails are showing the local lan IP address (192.168.xxx.yyy) in the subject and not the domain name / service_url.

Old reset emails I have don’t have an IP address in the subject…

If anyone knows what setting I need to change for that I would be grateful…

Can you check SEAFILE_SERVER_HOSTNAME and SEAFILE_SERVER_PROTOCOL in your .env file? What is the value of SEAFILE_SERVER_HOSTNAME?

SEAFILE_SERVER_HOSTNAME is the domain sf is running on - ie xyz.dynu.com in that format - a dynamic dns host

protocol is https