Enabling Rename / Move (Write Access)

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

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:

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.

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:

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:

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 means PICR can change your files and folders. If your admin password is leaked, or the server is hacked, an attacker could rename, move, or delete your media.
That’s why we keep 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.