Migration from .tar.gz based install to docker w/ franchetti/seafile-arm: no libraries?

Docker
, , ,
1

Hi,

I run my Seafile server on a Raspberry Pi 4 (32-bit). I’ve started some major versions ago, with a very manual install from the tar.gz bundles. I’m now on major version 8. For some time, I’ve started re-engineering my Pi 4 “home lab” installation through Ansible, so that the day that disaster strikes, I can recover faster. Seafile has been a pain, because, while anything can be automated with Ansible, the manual install I’ve done seems like a lot of work. I’ve been willing to start using some kind of Docker version for some time. The official containers do not support 32-bit ARM, so I’ve settled on the apparently excellent franchetti/seafile-arm. This also has the benefit of allowing to keep using SQLite instead of MySQL (I’m a single user with infrequent access and fairly limited amounts of data). The issue lies in properly migrating the data.

I’ve started the container once with a dummy volume. That container, with a new volume, creates a basic installation and configuration. I’ve then built a similar structure, reusing my existing conf and data folders.

When I bring it up on the new volume, some things seem to work; namely I can log in to the web portal (via nginx) with my real password rather than the one set up in the environment variables while starting the container. This tells me that the container detects the existing installation and does not overwrite the configuration with the default password.

However, even though I moved seafile-data, seafile.db and seahub.db to the rights places – I think ! --, when I land on the home page, I’m told I have no libraries.

Does anyone have experience of similar migrations, and have an idea of where I should look for a mistake?

For the sake of clarity, I include here the tree view of the volume I’m passing to the container.

tree -L 2
.
├── conf
│   ├── ccnet.conf
│   ├── gunicorn.conf.py
│   ├── __pycache__
│   ├── revision
│   ├── seafdav.conf
│   ├── seafile.conf
│   └── seahub_settings.py
├── logs
│   ├── controller.log
│   ├── onlyoffice.log
│   ├── seafile.log
│   └── seahub.log
├── media
│   ├── assets
│   ├── avatars -> ../seahub-data/avatars
│   ├── cors
│   ├── css
│   ├── custom -> ../seahub-data/custom
│   ├── fontawesome
│   ├── img
│   ├── js
│   ├── locales
│   ├── office-template
│   └── version
├── seafile-data
│   ├── httptemp
│   ├── library-template
│   ├── seafile.db -> ../sqlite/seafile.db
│   ├── storage
│   └── tmpfiles
├── seahub-data
│   ├── avatars
│   └── thumbnail
└── sqlite
    ├── GroupMgr
    ├── misc
    ├── OrgMgr
    ├── PeerMgr
    ├── seafile.db
    └── seahub.db

And my temporary docker-compose (meant to put things in place before I implement the setup in Ansible):

version: '2.0'
services:

  seafile:
    image: franchetti/seafile-arm:8.0.7
    container_name: seafile
    volumes:
    - /media/m3/docker-volumes/seafile:/shared
    ports:
    - 8924:8000 # to allow the previous install of seafile to keep running without conflict
    - 8926:8082
    environment:
    - TZ=Europe/Zurich
    - SERVER_IP=my.real.domain
    - USE_HTTPS=0 # nginx handles https
    - SEAFILE_ADMIN_EMAIL=p@domain.com
    - SEAFILE_ADMIN_PASSWORD=secret
    - SQLITE=1

    networks:
    - homelab

networks:

homelab:
external: true

Cheers,

Pierric.

2

Hi,

I never tried such a migration but I see no reasons it wouldn’t work.

Any error in the container log or in the files in the logs folder ?

It’s probably just an oversight, but what about your ccnet folder ?

3

Hi Barolo,

Thank you for your reply!

I’m stupid, I hadn’t thought of checking the logs folder in the docker volume! I was checking the docker logs, which showed nothing special. But I see a number of these lines in seafile.log:
2022-01-31 10:00:43 …/common/seaf-db.c(1212): Failed to open sqlite db: unable to open database file

However, I’ve rechecked, and the files are where I think they should be. They belong to user pi (uid=gid=1000), which is the uid/gid used by this container by default. The access mode is 644 on all the .db files. seafile-data/seafile.db is a soft link to sqlite/seafile.db, and it’s not broken or anything.

To your other question, indeed the ccnet folder content is there, although in this folder structure (that I deduced from running the container without any previous data, letting it create a base structure), its contents seem to be directly within the sqlite/ folder, so it doesn’t appear as a ccnet folder (it’s the GroupMgr, misc, OrgMgr and PeerMgt subfolders in there). Hope that makes sense.

What else could I check or try?

Cheers,
Pierric.

4

Oh, googling that error brought back bad memories, I think I know where the problem comes from.:
Try to use an absolute link (/shared/sqlite/seafile.db)

5

Boom! That was it! Indeed I remember now that this was how it was linked in the structure that the container auto-generated. However I didn’t realize my way of doing it would cause a big difference.

Thank you so much!

1 Like