Read-only external library metadata edits silently fail

[pyorot]

The bug

This has been discussed several times before, but there is an unintuitive behaviour where if a user edits metadata of an asset in an external library that's mounted as read-only (say by forgetting it's read-only or believing the edit would be stored in the database or generated files) then the edit silently fails.

A simple solution that came up in discussion is to issue a generic asynchronous popup to the client saying "failed to save metadata for <asset filename>: file system is read-only" or similar (and the log should mention "read-only" too).

The OS that Immich Server is running on

Debian 12

Version of Immich Server

v1.106.3

Version of Immich Mobile App

n/a

Platform with the issue

• Server
• Web
• Mobile

Your docker-compose.yml content

-

Your .env content

-

Reproduction steps

1. Edit date of asset in external library that's mounted as read-only in docker-compose.yml.
2. Click confirm.
3. Date in info pane doesn't change; 2 warnings in server logs.

Relevant log output

[Nest] 8  - 06/22/2024, 11:04:37 AM    WARN [Microservices:MetadataRepository] Error writing exif data (/mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp): Error: Error creating file: /mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp - /mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp
[Nest] 8  - 06/22/2024, 11:04:38 AM    WARN [Microservices:Error: File not found - /mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp
    at ReadTask._ExifToolTask_parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:76:71)
    at ReadTask.parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:47:167)
    at ReadTask._Task_resolve (/usr/src/app/node_modules/batch-cluster/dist/Task.js:146:40)] Error reading exif data (/mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp): Error: File not found - /mnt/assets/Pictures External/Vesna/2019-20 WhatsApp-Viber [Motorola G3]/IMG-20190816-WA0000.jpg.xmp

Additional information

No response

[wolginm]

Its funny, I've been 'reproducing' this bug for a few days now and pulling out may hair in the process.

I agree, that there should be some indication on the external library, or on the file. Maybe even gray out the options so the user knows whats going on. The silent fail felt very random.

I'm just glad its not me 😄.
I am going to try and loosen the permissions on the folder and see if it solves the issue for me.

EDIT: It did.

[ShinyYellowBanana]

I also seem to have silently failed here. I havent confirmed issue, but will verify later.

[kvalev]

What seems to be a bit weird is that when you add new tags, those will be saved, even tho xmp writing fails. However changing the date or the location straight up doesnt work. It will be nice if the behavior is consistent.

[pyorot]

What seems to be a bit weird is that when you add new tags, those will be saved, even tho xmp writing fails. However changing the date or the location straight up doesnt work. It will be nice if the behavior is consistent.

Does this mean the tags go in the database? 🤔

[bo0tzz]

The reason that happens is that extracting date or location from the file metadata overwrites what is in the database because an asset can only have one date or location, which doesn't apply to tags.

[jrasm91]

It should apply to tags as well. Tags are written to xmp and replaced on a subsequent metadata extraction.

[pypeaday]

FWIW I am having this issue with tags on my RO external library

[Nest] 7  - 09/19/2024, 10:19:28 AM   DEBUG [Microservices:LibraryService] Asset already exists in database and on disk, will not import: /mnt/nextcloud/Twitter/rwq17d.jpg

[Nest] 7  - 09/19/2024, 10:19:57 AM    WARN [Microservices:MetadataRepository] Error writing exif data (/mnt/nextcloud/Twitter/20240917_194444.jpg.xmp): Error: Error creating file: /mnt/nextcloud/Twitter/20240917_194444.jpg.xmp - /mnt/nextcloud/Twitter/20240917_194444.jpg.xmp

[Nest] 7  - 09/19/2024, 10:19:57 AM    WARN [Microservices:Error: File not found - /mnt/nextcloud/Twitter/20240917_194444.jpg.xmp

    at ReadTask._ExifToolTask_parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:76:71)

    at ReadTask.parser (/usr/src/app/node_modules/exiftool-vendored/dist/ExifToolTask.js:47:167)

    at ReadTask._Task_resolve (/usr/src/app/node_modules/batch-cluster/dist/Task.js:146:40)] Error reading exif data (/mnt/nextcloud/Twitter/20240917_194444.jpg.xmp): Error: File not found - /mnt/nextcloud/Twitter/20240917_194444.jpg.xmp

[Nest] 7  - 09/19/2024, 10:19:57 AM   DEBUG [Microservices:MetadataService] Asset ea468aeb-6745-4ff5-ba2c-bb87973658e0 date time is undefined

[Nest] 7  - 09/19/2024, 10:19:57 AM    WARN [Microservices:MetadataService] Asset ea468aeb-6745-4ff5-ba2c-bb87973658e0 has no valid date (undefined), falling back to asset.fileCreatedAt

[pypeaday]

can the xmp files or whatever be written somewhere else?

[basicfu]

+1 can the xmp files or whatever be written somewhere else?
I need to back up my gallery, but I don't want to see the xmp file when previewing through NAS

[bo0tzz]

They're sidecar files, storing them somewhere disconnected from the media doesn't really make sense.

[acbarrentine]

When the tag feature first went in, I was able to tag external (read-only) pictures. In subsequent updates, I have lost that functionality. Tags appear to apply, then disappear a few seconds later. In the log, I see the same kind of warnings reported above.

I could make the file system writeable, but I'd prefer not to. Something knows tags for my external files in that read-only file system made during the span where it worked. I suspect something went wrong with a revision and it is now trying to send that data to the .xmp files incorrectly

[Stronginthearm42]

When the tag feature first went in, I was able to tag external (read-only) pictures. In subsequent updates, I have lost that functionality. Tags appear to apply, then disappear a few seconds later. In the log, I see the same kind of warnings reported above.

I could make the file system writeable, but I'd prefer not to. Something knows tags for my external files in that read-only file system made during the span where it worked. I suspect something went wrong with a revision and it is now trying to send that data to the .xmp files incorrectly

+1
It seems to me that the "correct" option would be to store changed metadata for ro assets in the db.

[pyorot]

+1 It seems to me that the "correct" option would be to store changed metadata for ro assets in the db.

Ah but then the user would need to be told that that new metadata would only be reflected in immich rather than portably