Linux: PathTooLongException when scanning files with long UTF-8 filenames

[sichongzou 0]

Hello Emby team,

I am experiencing a PathTooLongException when Emby scans a media library on Linux.

After investigating the issue, I found a previous Emby community thread that appears to be very similar to my case:

Docker/Fedora 41 - Too long path error (actually it's not)
https://emby.media/community/topic/137639-dockerfedora-41-too-long-path-error-actually-its-not/

My environment:

• Emby Server: 4.10.0.40

• OS: Linux

• .NET: 8.0.28

• Docker deployment

• Architecture: x86_64

The error is:

System.IO.PathTooLongException: The path '/115_media/Media Library/GHS Media/Normal/雄神YUU' is too long, or a component of the specified path is too long.

at System.IO.Enumeration.FileSystemEnumerator`1.MoveNext()
at System.Collections.Generic.LargeArrayBuilder`1.AddRange(IEnumerable`1 items)
at System.Collections.Generic.EnumerableHelpers.ToArray[T](IEnumerable`1 source)
at Emby.Server.Implementations.IO.ManagedFileSystem.EnumerateFileSystemInfos(...)
at Emby.Server.Implementations.IO.ManagedFileSystem.GetFileSystemEntries(...)
at MediaBrowser.Controller.Providers.DirectoryService.GetFileSystemEntriesInternal(...)

What makes this interesting is that Linux itself can access the directory normally.

For example, inside the Emby container:

ls -la "/115_media/Media Library/GHS Media/Normal/雄神YUU"

works correctly and lists the files.

The problem appears to be related to the length of individual filenames rather than the total Linux filesystem path.

I measured the UTF-8 byte length of the .strm filenames and found many filenames between approximately 400 and 687 bytes.

For example:

687 bytes
679 bytes
677 bytes
675 bytes
...

The filenames contain a large amount of Chinese/other non-ASCII Unicode characters.

The previous community thread mentioned above appears to have found that truncating filenames to approximately 255 bytes avoids the problem.

However, renaming the files is not a practical solution for my setup. These are automatically generated .strm files and changing their filenames would affect my existing media library/NFO matching.

My question is:

Is this still a known limitation/bug in the Linux version of Emby?

More specifically:

• Is there a recommended workaround that does not require renaming the files?

• Has this issue been fixed or changed in a newer Emby version?

• Could Emby handle this exception during directory enumeration so that files with long UTF-8 filenames do not prevent the rest of the directory from being scanned?

• Is there a plan to support filenames longer than approximately 255 UTF-8 bytes on Linux?

The fact that Linux can enumerate the files normally with ls, while Emby's .NET System.IO.Enumeration.FileSystemEnumerator throws PathTooLongException, makes me suspect this is related to the .NET/Emby filesystem enumeration layer rather than an actual Linux filesystem path limitation.

Any guidance from the development team would be greatly appreciated.

Thank you.

[Luke 43152]

Hi there, please attach the Emby server log from when the problem occurred:

How to Report a Problem

Thanks!

 

[sichongzou 0]

3 minutes ago, Luke said:

您好，请附上问题发生时Emby服务器的日志：

如何报告问题

谢谢！

 

Oh, sorry, this is a log

embyserver.txt

[sichongzou 0]

May I ask if the problem has been successfully located? Is there anything I can assist in providing