Storage

VidArch separates application state from voluminous media.

data/

This directory contains the SQLite database, optional cookies, the session secret, and cached resources. It is essential for a consistent restoration.

downloads/

This directory contains downloaded videos, thumbnails, and metadata. Its size depends directly on the duration and quality of the videos.

Recommendations

• Use persistent mounts;
• Monitor free space before enabling automatic downloads;
• Back up data/ and downloads/ at the same time;
• Do not mount these folders from an unstable share;
• Avoid any synchronization that could modify the database while it is in use.

Bind-mount permissions

The published image runs as the non-root identity 1000:1000. A host directory mounted at /app/data or /app/downloads must therefore be readable and writable by UID 1000. Check the current state first:

stat -c '%u:%g %A %n' ./data ./downloads

For the default directories dedicated to VidArch, create them and assign the expected owner before the first start:

mkdir -p ./data ./downloads
sudo chown -R 1000:1000 ./data ./downloads

For an existing shared media library, POSIX ACLs grant VidArch access without replacing its current owner:

sudo setfacl -R -m u:1000:rwX /path/to/media-library
sudo setfacl -m d:u:1000:rwx /path/to/media-library

Then use the absolute host path in Compose:

volumes:
  - ./data:/app/data
  - /path/to/media-library:/app/downloads

Verify the effective permission after starting the service:

docker compose exec vidarch sh -c 'id && test -w /app/data && test -w /app/downloads && echo writable'

If setfacl is unavailable on Debian or Ubuntu, install the acl package. Avoid chmod 777: it grants write access to every local account and container instead of granting only the identity that needs it.

The Settings → Storage & Files page displays the used space and allows purging the ephemeral cache without deleting the archives.