PR #3388 added hardlink-based asset import/export (os.link with a
shutil.copy2 fallback) to avoid duplicating disk space. The Dockerfile
VOLUME instruction listed each /romm subdirectory (resources, library,
assets, config, sync) separately, which makes Docker create an
independent mount point for each one — even when the user bind-mounts a
single parent at /romm. Each mount point is its own st_dev, so every
cross-directory os.link() failed with EXDEV and silently fell back to a
full copy, defeating the optimization.
Declare the parent /romm directory instead so all subdirectories share a
single filesystem and hardlinks can succeed when paths reside on the same
underlying host filesystem.
The default Docker image symlinked /romm/assets into the nginx static web
root (/assets/romm/assets), where it was served by an unauthenticated
`location /assets { try_files ... }` block. /romm/assets holds private user
data (save files, save states, screenshots, avatars) that is meant to be
accessible only through the authenticated /api/raw/assets/{path} route
(Scope.ASSETS_READ). The static symlink bypassed that protection, letting any
unauthenticated caller read another user's files given a (guessable) path.
Avatar URLs leaked the hex user ID through the same static route, making path
construction straightforward.
Fix:
- Drop the /romm/assets symlink from the Docker image build and both
entrypoint scripts; only /romm/resources (public cover art, screenshots,
manuals) remains statically served.
- Point the frontend avatar URLs at the authenticated /api/raw/assets/ route
instead of /assets/romm/assets/. Browser <img> loads authenticate via the
existing session cookie.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Move the sync staging folder out of ROMM_BASE_PATH so it lives on a
dedicated writable mount. This lets the container run with a read-only
root filesystem without losing in-flight save uploads, and keeps
app-owned state separate from the user-curated library volume.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Related `mod_zip` issue https://github.com/evanmiller/mod_zip/issues/90
has been fixed in commit
288d66541c
By upgrading `mod_zip` to include this fix, we can remove the workaround
that involved using a separate internal location and server to serve
files for zipping.
* Added `linux-headers` back, but only for development stage.
* Fixed initialization script, as `uv` is not included in the final
Docker image.
* Initialize variable `ENABLE_SCHEDULED_UPDATE_LAUNCHBOX_METADATA`.
The `production-stage` stage was depending on the `python3` package from
Alpine, which at the moment of writing is still Python 3.12.
To avoid relying on Alpine's package and releases, we now copy the
Python installation directly from its official Docker image.
Other options were tested but did not work:
- Trying to install Python 3.13 using `apk`. As mentioned, Alpine does
not support Python 3.13 yet.
- Installing Python 3.13 using `pyenv`. The installation worked, but the
generated image was too large. Related `pyenv` discussion:
https://github.com/orgs/pyenv/discussions/2868
- Installing Python 3.13 using `uv`. Only worked for `amd64`
architecture, but the installation failed on `arm64`.
The previous attempt to upgrade RALibretro before a new tagged version
was available (#1970) needed to be reverted, as the RAHasher tool failed
with segmentation faults in some scenarios.
Bump `RALibretro` to the latest commit from the upstream repository.
Removes the need to use an older version of Alpine Linux, but requires
some changes to the `RALibretro` source code to compile successfully.
The `nginx` image is still not available for Alpine 3.22, but we can
also upgrade to its latest patch version (`1.27.5`).
