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.

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

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.

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? 🤔

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.

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

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

can the xmp files or whatever be written somewhere else?

+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

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

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

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.

+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

Yes, but since the library is read-only, this shouldn't be surprising.

I think that all libraries, not just read-only ones, should have metadata like descriptions, tags, and ratings stored in the database by default. This approach would provide a central, reliable repository for metadata management, and users could then elect to export this metadata to individual XMP sidecar files for all images or an individual image if desired. This flexibility would allow for more efficient organization and metadata handling across all library types without altering the original files unless chosen explicitly by the user.