How does culling (to trash, move to folder) work?

[jarppiko]

Hello,

I run Facet as a container using Podman. It seems it runs as rootless container since the facet user id is different from my user id.

Problems

1. When I try to "Cull to folder", I get "access denied" regardless do I try to copy selected, move rejected or trash the rejected. podman logs does not show anything.
2. I am also confused what is the folder I should select. Is it relative to container root, relative to PHOTOS_DIR or something else?

Is this related to the facet user inside container having a different user id than my user account on the host side?

[MLuc24]

It's not the UID — that "access denied" is a deliberate 403 from Facet's own path check, which is why nothing shows up in podman logs. Nothing errored; the API just declined and returned a normal response.

The check is _validate_target_dir in api/routers/export.py, and it's fail-closed:

real = os.path.realpath(target_dir)
roots = _allowed_export_roots()
if not roots:
    raise HTTPException(
        status_code=403,
        detail="Copy/symlink export is disabled — configure viewer.export.allowed_target_dirs",
    )
for root in roots:
    if real == root:
        return root
    if real.startswith(root + os.sep):
        return real
raise HTTPException(status_code=403, detail="target_dir is not an allowed export location")

The allowed roots come from two places:

Configured ``viewer.export.allowed_target_dirs`` first, then the scan
directories (so exporting within the photo tree works out of the box).

So if you haven't set viewer.export.allowed_target_dirs, the only writable destinations are your scan directories — anywhere else is refused regardless of filesystem permissions. That's the fix: add the folder you want to viewer.export.allowed_target_dirs, or pick somewhere inside the photo tree.

That also answers your second question. os.path.realpath runs inside the container, so the path you type is the path the container sees — the mount point, not your host path. If your compose maps a host directory to /photos, you enter /photos/rejects, never the host-side path. Anything else canonicalizes to something with no matching root and gets the same 403.

If you're still refused after adding it, the thing to check is that the destination is on a volume actually mounted into the container. realpath resolves symlinks before comparing, so a path that resolves outside the mount fails the containment test even when it looks correct from the outside.

Filesystem ownership only becomes relevant once you're past this — at that point the failure mode changes to an actual error in the logs rather than silence, which is a useful way to tell the two apart.