Anaphora v0.8.104 -- anaphora ran without any configuration in place :/

General
1

Hello Paul, There is something wrong with our Anaphora instance, I was off for a while and yesterday morning I see there are no more jobs or any configuration present:

image
image595×373 37 KB

image
image594×207 49.8 KB

I restore a backup from the 14th of March 2025. But I’ve no idea why the configuration was missing :confused:

Any idea ?

kr,
Gautier.

nb: I add the idea of creating an API to export configuration; My idea is to schedule a daily export of the configuration to be able to restore everything quickly and it may help us to deploy anaphora on another instance as well etc.

ps: the instance is now running in the latest version available: v0.8.105

2

Oh no! Can it be that the container was restarted and the config was stored in a file contained in a directory that was not mounted in the host filesystem?

Anyway +1 for the Backup/Restore API.
@gautier.franchini would it be more practical to store that in S3?

3

The docker-compose configuration never change, it is always:

      - ./content/:/usr/src/app/content/:rw # ## Mount PDF reports
      - ./storage/:/usr/src/app/storage/:rw

Of course it could be great to have the possibility to choose the storage type and have an s3 bucket.

BUT in right now the storage type is not a problem; the the problem is that I don’t understand why everything disappeared :confused:

A server reboot, an anaphora container upgrade or docker-compose down/up should have an impact as we store everything on disk.

4

@AntonioV anything comes to mind about this one?

5

Did the system settings also get reset? Like the local users for example.
The system settings are stored in the same folder but in a different file. If they are still the same, this could narrow down the error.

6

I encountered the same issue this morning; I think it came from the ownership:

in my Anaphora working directory: ~/Workspace/ ; I have the following:

content/
storage/
docker-compose.yml
. . .

and the ownership was set to:

  • user: ubuntuadmin
  • group: packer

Whenever anaphora container is top the ownership of storage change from ubuntuadmin:packer to packer:packer ; I think this is the rootcause.

I add the packer group to my ubuntuadmin user groups.

At the end I should probably create a dedicated user to avoid any issue.

kr,
G.

ps: That being said, I install the latest v.0.8.111.

7

That’s an interesting finding — conflicting permissions between the host and container could definitely be the issue.

One possible solution is to use Docker-managed volumes instead of bind mounts. For example:

  - anaphora-content:/usr/src/app/content:rw
  - anaphora-storage:/usr/src/app/storage:rw

This way, Docker handles the ownership and permissions, so you avoid potential conflicts with host file system permissions.