Conversions filling system disk: Any way to set a storage cap?

[me@jackbenda.com 7]

I've been experimenting with Emby's built-in conversion feature and ran into a problem I suspect others have hit too: conversions writing to the system disk until it's completely full.

The Conversions settings page only gives me two controls: A temporary file path and the full speed toggle. There's no native option to limit how much disk space conversions are allowed to use, or to cap the queue size.

My setup: Emby running natively on Ubuntu Server 24.04, 231GB NVMe system disk. When I kicked off a batch of conversions, Emby happily wrote to /var/lib/emby/sync/ until the drive was full. No warnings, no throttling, just a dead server.

A few questions for the community:

1. Is there a setting I've missed that limits conversion disk usage? I've only found the temporary file path and the speed toggle.
2. Is there a way to limit how many conversions run concurrently, to at least control the rate at which disk is consumed?
3. For those running conversions on a system disk — what's your approach? Redirect to a separate drive, or something else?

If this genuinely isn't possible natively, I'll put in a feature request: A maximum disk usage cap for conversions seems like a fairly essential guardrail. Keen to hear how others are handling this before I go the OS-level workaround route (create a dedicated directory on the NVMe for conversions, then enforce a hard size limit using a fixed-size loopback mount. Emby hits the ceiling and stops. system disk is safe. I'd point the "Temporary file path" at that mount. The cap is whatever I set, say 50GB, and nothing else on the disk is at risk. I'm just worried that that could freeze Emby up entirely though.)

[Q-Droid 1013]

Conversions should not fill up the space unless there's a problem with the job or a bug. Each file that's converted is copied back into the library based on the settings (replace or new version) and the temporary work file should be deleted. 

If there's a problem copying the file back then work files could be left behind. Usually because the library folder (directory) or the source media file itself have the wrong ownership and/or permissions that keep Emby from creating or overwriting. Other problems or failures during conversion could also leave files behind.

The activity should be logged along with possible errors. Enable debugging to get more detail in the logs.

 

[Luke 42314]

Quote

If there's a problem copying the file back then work files could be left behind. Usually because the library folder (directory) or the source media file itself have the wrong ownership and/or permissions that keep Emby from creating or overwriting.

Hi, yes this is the most common reason for conversions taking up a lot of disk space.

[me@jackbenda.com 7]

This is a really helpful pointer. This issue arose just before i went on holiday on the 1st of April, and I don't have those logs any more. I've just updated all the permissions and I'm running a few things as a trial run. Hopefully this will work!

Big thanks to both. 

[Luke 42314]

Was this what happened?

[me@jackbenda.com 7]

No I don't think so. I double checked and I did already have all the permissions set. I honestly don't know what happened last time, but it does seem to be working now and I've got a telegram bot to warn me if the directory starts ballooning again. 

[me@jackbenda.com 7]

OK so after enabling debug logging and running some test conversions, I can confirm the conversion feature itself works well. QuickSync hardware encoding, files writing correctly to the temp directory, replacements landing in the right place. No permissions issues (emby user is in the correct group with write access to the NAS shares).

The problem I hit was a resilience issue rather than a conversion bug. Here's what happened:

1. Emby was mid-conversion, writing finished files back to the NAS via the Transfer media task
2. My (slightly crap) NAS became temporarily unresponsive under load
3. The CIFS/SMB mount hung at the kernel level which i think is a known Linux behaviour where processes with open file handles on an SMB share block indefinitely waiting for the server to respond
4. Emby's Transfer media task stalled on "Stopping" and couldn't be cancelled from the UI
5. The only recovery was a full server reboot

This isn't really an Emby bug, it's a Linux kernel CIFS behaviour. But it does raise a question about whether Emby could handle NAS disconnects more gracefully during conversion transfer, perhaps with a configurable timeout or retry mechanism rather than hanging indefinitely.

On the Linux side, the fix is to add echo_interval and echo_retries options to the fstab CIFS mount, which reduces the time before the kernel declares the server dead from ~5 minutes to ~60 seconds. But even with that, processes in uninterruptible sleep will still hang temporarily.

Is there a cleaner way to handle this? Specifically, whether Emby has any internal timeout on file transfer operations that could be configured.

[Q-Droid 1013]

If you're running Linux to Linux then NFS might be more reliable.