[Bug] Emby tries to delete JPG/metadata files on Read-Only disks, blocking Metadata db updates

[eduncan911]

Thank you for all the hardwork on Emby. As a premium subscriber, we've been using it extensively for years. :)

Issue:

Emby is attempting to delete metadata JPGs it does not own. Even if configured to store/cache the thumbnails elsewhere, it still continues to try to delete the remote Read-Only version that is not part of it's configuration for cache/metadata storage location.

Since the /media directory is READ-ONLY, Emby throws an unhandled exception and fails to update the Metadata database for the new location of the downloaded Thumbnail it just downloaded. Therefore exiting the entire sub-routine.

Expected Behavior:

Preferred:

Emby does not delete files it does not own/index/use (like this thumbnail JPG I already have).

Acceptable:

Emby logs that it cannot delete the thumbnail; but, continues to update the Metadata database for the already successfully downloaded JPG thumbnail into its configured cache location.

Behind the Scenes steps that cause the issue

I highly suspect the backend code/sub-routine is doing the following pseudocode in order:

public void UpdateThumbnail(context...) {
  try {
    
    // this works
    DownloadThumbnail(context);

    // this throws an AccessDenied exception
    DeleteAnyExistingThumbnails(context);

    // so this is never reached due to exception above
    UpdateMetadataDatabaseForThumbnail(context);
    
  } catch (Exception e) {
    throw e;
  }
}

I recommend changing the order for the DeleteAnyExistingThumbnails() to be at the end of the global try/catch.

Or, properly handle the exception like the following:

public void UpdateThumbnail(context...) {
  try {
    DownloadThumbnail(context);
  } catch (Exception e) {
    throw DownloadException(e);
  }

  try {
    UpdateMetadataDatabaseForThumbnail(context);
  } catch (Exception e) {
    throw UpdateMetadataException(e);
  }

  try {
    DeleteAnyExistingThumbnails(context);
  } catch (Exception e) {
    throw DeleteException(e);
  }
}

That way, if Emby is unable to delete, at least the transaction continues to update the metadata of the downloaded file.

How to Reproduce:

• Configure Emby to NOT store metadata files next to the media files. Use the default setup, to store JPGs to local disk, cache, etc.
• Add a READ-ONLY media folder, such as /media/movies/Whatever (1933)/. Ensure Emby only has RO access to this directory.
• Place a media file (e.g. MKV, MP4, etc) there, along with a JPG thumbnail as RO at /media/movies/Whatever (1933)/Whatever (1933).jpg.
• Now, index that /media folder within Emby. You'll see that Emby is unable to display the JPG thumbnail, and shows a preview of the movie file itself.
• Finally, attempt change the Thumbnail image of that Movie. While you will see the downloaded thumbnail now in Emby (possibly, unless it stalls due to the exception), it's only temporary until you restart the Emby server, or wait a few hours.

At this point, if you view the embyserver log, you'll see it successfully downloaded the new Thumbnail image into the cache. However, the next log entry is an error with Emby attempting to delete the /media/movies/Whatever (1933)/Whatever (1933).jpg but it logs an exception.

Emby therefore exists the overall transaction and does not continue updating the metadata database for the new downloaded image. E.g. a Try/Catch block that just exits the entire subroutine when any exception is thrown, and doesn't continue to update the metadata database after the delete fails.

Emby should not try to touch files it does not own, unless you tell it to! Or at least, ignore modifying files if accessing a read-only folder (and log read-only was detected).

Additional Info

Why can't Emby display this read-only JPG anyways? It obviously is trying to delete it, so it knows its there - so why not just show it?

The Exception

Here is an example error message:

2025-08-08 19:23:36.759 Info ProviderManager: Saving image to /config/metadata/library/20/20395b3c5d192d89baa870087b03f39d/poster.jpg
2025-08-08 19:23:36.763 Info ProviderManager: Deleting previous image /movies/Venom Let There Be Carnage 2021 2160p UHD BluRay REMUX DV HDR HEVC Atmos-TRiToN/Venom Let There Be Carnage 2021 2160p UHD BluRay REMUX DV HDR HEVC Atmos-TRiToN.jpg
2025-08-08 19:23:36.767 Error RemoteImageService-0HNELFTJ92GQT:00000001: Error processing request
	*** Error Report ***
	Version: 4.9.1.7
	Command line: /system/EmbyServer.dll -programdata /config -ffdetect /bin/ffdetect -ffmpeg /bin/ffmpeg -ffprobe /bin/ffprobe -restartexitcode 3
	Operating system: Linux version 6.6.44-production+truenas (root@tnsbuilds01.tn.ixsystems.net) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1
	OS/Process: x64/x64
	Framework: .NET 8.0.11
	Runtime: system/System.Private.CoreLib.dll
	Processor count: 2
	Data path: /config
	Application path: /system
	System.UnauthorizedAccessException: System.UnauthorizedAccessException: Access to the path '/movies/Venom Let There Be Carnage 2021 2160p UHD BluRay REMUX DV HDR HEVC Atmos-TRiToN/Venom Let There Be Carnage 2021 2160p UHD BluRay REMUX DV HDR HEVC Atmos-TRiToN.jpg' is denied.
	 ---> System.IO.IOException: Permission denied
	   --- End of inner exception stack trace ---
	   at System.IO.FileSystem.DeleteFile(String fullPath)
	   at Emby.Providers.Manager.ImageSaver.SaveImage(BaseItem item, LibraryOptions libraryOptions, IImageSource source, ReadOnlyMemory`1 mimeType, ImageType type, Nullable`1 imageIndex, Nullable`1 saveLocallyWithMedia, Int64[] generatedFromItemIds, IDirectoryService directoryService, Boolean updateImageCache, CancellationToken cancellationToken)
	   at Emby.Providers.Manager.ProviderManager.SaveImageFromRemoteUrl(BaseItem item, LibraryOptions libraryOptions, String url, ImageType type, Nullable`1 imageIndex, Int64[] generatedFromItemIds, IDirectoryService directoryService, Boolean updateImageCache, CancellationToken cancellationToken)
	   at Emby.Api.Images.RemoteImageService.DownloadRemoteImage(BaseItem item, BaseDownloadRemoteImage request)
	   at Emby.Server.Implementations.Services.ServiceController.GetTaskResult(Task task)
	   at Emby.Server.Implementations.Services.ServiceHandler.ProcessRequestAsync(HttpListenerHost httpHost, IServerApplicationHost appHost, IRequest httpReq, IResponse httpRes, IStreamHelper streamHelper, RestPath restPath, String responseContentType, CancellationToken cancellationToken)
	   at Emby.Server.Implementations.HttpServer.HttpListenerHost.RequestHandler(IRequest httpReq, RestPath restPath, ReadOnlyMemory`1 urlString, ReadOnlyMemory`1 localPath, String contentTypeInPath, CancellationToken cancellationToken)
	Source: System.Private.CoreLib
	TargetSite: Void DeleteFile(System.String)
	InnerException: System.IO.IOException: Permission denied
	Source: 
	TargetSite: 

[eduncan911]

I'd be more than happy to attempt a PR at this. However, I am not a developer here on Emby and have zero clue as to where to look.

If someone can point me to the function/method that is doing this, I'd be happy to take a shot at a PR. :)

[eduncan911]

Aiight, I looked at the stacktrace. It's C# and it looks like this is the line throwing the exception:

Emby/MediaBrowser.Providers/Manager/ImageSaver.cs

Line 173 in 1d7c2ab

_fileSystem.DeleteFile(currentPath);

---

I see two ways to move forward:

1. How about we edit these conditions to test for READONLY, and ignore?

Emby/MediaBrowser.Providers/Manager/ImageSaver.cs

Line 163 in 1d7c2ab

if (currentImageIsLocalFile && !savedPaths.Contains(currentImagePath, StringComparer.OrdinalIgnoreCase))

(I'm still confused as to why Emby wants to delete a thumbnail that doesn't match the new cache path.)

or...

2. We can simply add another try/catch for System.IO.IOException and/or System.UnauthorizedAccessException like this one:

Emby/MediaBrowser.Providers/Manager/ImageSaver.cs

Lines 175 to 178 in 1d7c2ab

	catch (FileNotFoundException)
	{
	}

I'd also suggest we log these exceptions, instead of just ignoring them.

---

I'll attempt a PR if this is the way forward. Just let me know!

[LukePulverenti]

HI, someone had a question in the community recently and I gave an explanation there. Was that you?

[eduncan911]

HI, someone had a question in the community recently and I gave an explanation there. Was that you?

Yep. Unfortunately I wasn't able to convey the proper usecase/logic properly in the forums there.

I found the bug in that the transaction fails to complete because of the unhandled exception, and have suggested a fix above.

I'll submit a PR if this is the correct path. I just have no way to test it since Im not setup for .NET/VS (Linux user).

[LukePulverenti]

The problem, as explained in the thread, is that the system will always prefer the local image. This will lead you into thinking that the manual image editor isn't working.
There is currently no provision for preferring a different image if you have one sitting next to your video file. So that is what would have to happen.

[eduncan911]

The problem, as explained in the thread, is that the system will always prefer the local image. This will lead you into thinking that the manual image editor isn't working. There is currently no provision for preferring a different image if you have one sitting next to your video file. So that is what would have to happen.

Please read the OP above, in detail. That is not the problem, as explained in the thread, everyone mis-understood the problem.

I have detailed a simple work around that complies to the existing workaround in the code base in post 3 above.

Shall I submit a PR with it?

[LukePulverenti]

I did read it, and I'm pretty sure I understand what you're saying. If we do what you're saying, then you'll configure a new image in the image editor, and then the next library scan will change it back to the old one.

That is why the true answer is that we need a provision for preferring a different image, then we will no longer have to try to delete the existing one at all.

[eduncan911]

If I understand correctly, the library scan will purposely revert the UI-user-specified thumbnail that was downloaded and saved in local cache. It does this because during that re-scan, it finds a jpg. next to the media file on the next scan.

If that's the case, it sounds like the logic within the scanner should change. Perhaps something like:

1. Thumbnail found next to media file.
2. Check if metadata has user-specified thumbnail(s), and if so, ignore the jpg next to the media file.
3. If no metadata/user-overwritten entry exists, continue doing what it does now.

Sounds like the scanner is too aggressive and needs additional lookups before using the local media jpg.

---

Another thought would be a user-preference Boolean of something like, "Prefer thumbnail next to media" that the scanner would follow.

IMO, this is confusing logic because if that flag is True, and the end user attempts to change the thumbnail (because it's so easy to do in the UX), it would bring us right back here, because of the Read-Only error stated above in the OP, and the user experiencing exactly what I am experiencing currently.

[eduncan911]

@LukePulverenti would you be able to point me to the relevant bits of the Scanner that performs this logic?