Enable rename and move access

Start read-only

You can run PICR in read-only mode and enable this later, once it is needed.

Before enabling writes, make sure both your media and PICR database have current backups. See Backups and upgrades.

By default PICR only has read access to your media folder. This is the safest option.

If you want to rename or move folders from inside PICR, you must enable write access in two places:

1. Environment variable

   • Add CAN_WRITE=true to the environment: section for the picr service.

2. Docker volume mount

   • Change the media mount from read-only (:ro) to read-write (:rw), or just remove :ro.

Example:

compose.yml — enable media writes

services:
  picr:
    volumes:
      - /path/to/your/media:/home/node/app/media:rw
    environment:
      - CAN_WRITE=true

Synology / NAS note (common issue)

When CAN_WRITE=true, PICR checks write support by creating and deleting a hidden .picr-write-test-* file in /home/node/app/media during startup. It does not rely on POSIX mode bits alone.

On Synology DSM and some NFS mounts, DSM ACLs can allow writes even when the NFS client reports the folder as something like 555 / dr-xr-xr-x. That is OK: if the hidden probe file can be created and deleted from inside the container, PICR will report canWrite: true.

If CAN_WRITE=true but PICR still reports canWrite: false, the startup warning will include the actual probe error code/message, plus the container runtime UID/GID and media path owner/mode.

On NFS mounts, check the reported mode as well as the owner. If PICR logs the same UID/GID for the runtime user and the media path owner, but the media path mode is 555, the NFS mount is still exposing the directory as read-only to the container. In that case, changing the Docker user: line will not help until the NFS export, NFS client mount options, Synology ACLs, or Docker volume mode expose write permission.

Short Version

• Set the CAN_WRITE=true then run PICR.
• PICR will try to create and delete a hidden .picr-write-test-* file in the media root.
• If that fails, you will get a “you tried to enable write access but the write probe failed” warning with the real filesystem error and exact IDs to add to docker compose.
• Add those, then restart the container.

Long Version

PICR runs as a non-root user by default. On NAS systems (especially Synology DSM), the mounted folder often belongs to different UID/GID values than the container user.

Recommended approach:

1. Keep PICR non-root.
2. Run picr container with user: "<media-owner-uid>:<media-owner-gid>".
3. Ensure that UID/GID has write permissions in DSM folder ACLs.

Example:

compose.yml — run as the media owner

services:
  picr:
    user: '1026:100'
    volumes:
      - /volume1/photos:/home/node/app/media:rw
    environment:
      - CAN_WRITE=true

You can quickly test from inside the container:

Test media writes from the container

docker exec -it picr sh -lc 'id; ls -ld /home/node/app/media; test_file="/home/node/app/media/.picr-write-test-manual-$(date +%s)"; printf "picr-write-test\n" > "$test_file" && rm "$test_file"'

Why this is risky

Write access expands the impact of a compromised server

Write access means PICR can change your files and folders. If an administrator password is leaked or the server is compromised, an attacker could rename, move, or delete media. That is why PICR keeps write access off by default.

If you enable it, make sure you:

• Use a strong admin password.
• Keep your server and Docker images up to date.
• Use a reverse proxy, preferably something with fail2ban or other types of security.
• Keep backups of your media and database.

You should obviously be doing this anyway, but it’s extra important if it’s possible to modify files in the media folder.

Why would I do this?

PICR is designed to allow you to manage your files outside of PICR (EG: on a network drive).

Unfortunately when you rename a folder that is usually detected as a “folder deleted” and then a “new folder” shortly after. PICR tries to work out that it’s just a rename but that doesn’t always work so sometimes the renamed folder will appear as a new folder. This means it will lose all the users/ratings/comments etc associated with it. Moving/renaming from within PICR ensures that all the data is still linked.