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 43166]

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

[bkettering 0]

Not staff, but one thing worth checking while you wait on Luke: on Linux the 255 limit is per file or folder name in bytes, not characters, and each Chinese/Japanese character is 3 bytes in UTF-8. So a name that looks like 90 characters can already be over. This lists anything in that folder over 200 bytes:

find "/115_media/Media Library/GHS Media/Normal/雄神YUU" | while read -r f; do n=$(basename "$f"); b=$(printf %s "$n" | wc -c); [ "$b" -gt 200 ] && echo "$b  $n"; done

If something shows up near or over 255, shortening that one name usually clears it. If nothing does, it's more likely the cloud mount itself (the old thread you linked ended up being that), and your log is the way to go.