Server Version#: 1.41.5.9522
Player Version#: 4.145.1
Jails are now deprecated in Truenas Core. So I opted to leave the NAS alone and use it solely for storage and migrate Plex server to a Windows-based NUC.
After installing the server I added a Movies library pointed to the media on my NAS. The vast majority of my library did NOT get picked up by the scanner. I pulled my hair out a bit checking and re-checking permissions and even tried using Samba instead of NFS.
Turns out the problem was one file with a somewhat malformed filename.
The log is filled with entries such as these:
Apr 11, 2025 16:01:23.558 [11908] ERROR - Couldn’t get size of file “N:\Movies\Mrs. Doubtfire (1993)\Mrs. Doubtfire (1993).mp4”: boost::filesystem::file_size: The system cannot find the file specified [system:2]: “N:\Movies\Mrs. Doubtfire (1993)\Mrs. Doubtfire (1993).mp4”
Apr 11, 2025 16:01:23.558 [11908] ERROR - Couldn’t get size of file “N:\Movies\Mrs. Doubtfire (1993)\Monkey Man (2024)”: boost::filesystem::file_size: The system cannot find the file specified [system:2]: “N:\Movies\Mrs. Doubtfire (1993)\Monkey Man (2024)”
Apr 11, 2025 16:01:23.558 [11908] ERROR - Couldn’t get size of file “N:\Movies\Mrs. Doubtfire (1993)\March of the Penguins”: boost::filesystem::file_size: The system cannot find the file specified [system:2]: “N:\Movies\Mrs. Doubtfire (1993)\March of the Penguins”
The Monkey Man and March of the Penguins movies do NOT live under Mrs. Doubtfire in the directory hierarchy. So that was a clue. I looked more closely at my Movies folder and found the following file named exactly as shown:
Mrs. Doubtfire (1993)\Mrs. Doubtfire (1993).mp4
I no doubt accidentally created that file trying to mv the file into the Mrs. Doubtfire directory (which it turns out was indeed empty).
Getting rid of that file enabled Plex to correctly scan all my media.
Not sure how that filename caused downstream scanner effects, but this is clearly a (rather niche) bug.
I can provide the full log, but I think this information is sufficient to repro.
<If providing server logs please do NOT turn on verbose logging, only debug logging should be enabled>
I reported a related bug to this several years ago and got told that Plex would not support this because the filename, which is valid on my operating system, would not be valid on a different operating system I don’t use. As a result, I expect the odds that someone will help you or take any action to resolve this issue are poor. Sorry.
Ultimately, what can we expect in terms of support? It’s not like we pay money for Plex. Oh wait, we do! Weird!
I don’t need support in this instance. I already figured out the problem and fixed it. But I felt obliged to report the bug. If they don’t want to open a bug or resolve it as won’t fix, so be it.
But as a dev I personally would find it pretty alarming to have data leak this way. The existence of that file somehow tricked the scanner into thinking other files were in a different location than they actually are. I wonder what architecture would enable that? If it were open source, I’d probably take a look out of some morbid sense of curiosity.
I looked at your bug. The scale of that bug and its impact was limited to the one file.
This bug meant most of the library silently failed to scan. Well, not completely silently, the logs helped. But even then, there was just a clue as to the problem. But that’s not a great user experience… Still, I stand by what I said in the original post. This is pretty niche and parsing code is notoriously fragile so I think you’re right, this won’t get fixed.
Speaking of morbid curiosity, what filesystem is in use for the volume where this file was stored on the NAS? And what type of share is it (SMB/CIFS, NFS, something else)?
I ask because I did a test where I created a file named as yours above on an EXT4 filesystem and shared it from an Ubuntu Linux host via SMB (3.11) as a mapped drive on a Windows 11 Pro system. Something in the chain rationalized the name to an 8.3-compatible version: MRHPXS-V.MP4.
Further, when I created a new movie library and pointed it to the folder which contained that file, it scanned the library and found it by its rationalized name.
So I’m a little curious about your environment, and how the file escaped being turned into an 8.3 stand-in.
The media is stored in a ZFS dataset on FreeBSD-based TrueNAS Core. Windows 11 normally accesses the media via an NFSv3 share (because other apps on the NUC take advantage of hard links, and though purportedly Samba can be configured to provide hard links, it’s apparently flaky so why bother). That said, I tried using a Samba share too and with the same result. Just removing the offending file fixed the scanner and Plex picked up all the movies. To be more precise, I moved (and renamed) the file into its correct folder. Problem solved…
I have seen the 8.3 normalized files you are describing in, for example, an Explorer window in the past. But I just realized, I don’t have any idea what the file looked like on the Windows side. It may well have been mapped to 8.3. I “discovered” the offending file reviewing the media folder from an SSH console. So the filenames would appear in their native format there…
It’s a strange issue. I’ve got a TrueNAS Scale VM so I might see if I can more closely mimic your configuration (ZFS dataset exported via NFSv3).
Plex is using Boost libraries for cross-platform portability. Boost’s filesystem libraries provide so-called “name_check” functions (portable_posix(), portable_windows(), etc…) so they certainly could (should?) be checking name validity before doing anything else with the files. But the 8.3 mapping has me wondering if they’d even be useful here.
That’s just it though. It’s an actual file name that contains the backslash. As in, this is the file name: "Mrs. Doubtfire (1993)\Mrs. Doubtfire (1993).mp4"
That backslash is embedded in the file name itself.
Of course that’s completely illegal in Windows, no one disputes that. But it’s allowed in Linux for certain filesystems and that filesystem was shared via NFSv3. And it apparently had side-effects, causing other files to be seen in an incorrect path (see the first post for details on that).
How do you know? A file name like that doesn’t make sense anyway. It does make sense if you read the part before the backslash as a folder name. Because that is exactly the recommended naming schema. Each movie in its own subfolder.
And yes, it is illegal in Windows. If you try and serve that to Windows, you can be sure of unintended side effects.
The OP thinks they accidentally created the malformed file with an errant copy operation. Trying to move the file to a sub-directory and including a mis-placed backslash (including two back-to-back would have escaped it and leaked it into the filename. That’s how I reproduced it here).
Indeed, when I tested here Samba did normalize the name to something compatible with Windows (an 8.3 name). Well, I assume it was Samba that did it. But the OP was using NFSv3 which may present a more faithful representation of the name.
I’ve got a TrueNAS server here and will likely do some testing. For science.
That is not a legal character for windows. It is likely not a “\” but some other special character that Plex can’t interpret. Best to rename the file and replace that character with something else.
Yes, we know (and discussed it above). Not (personally) really expecting Plex to do much with this, I was more checking it out for funsies.
However, it’s worth mentioning that having that file exposed to Windows like that has side-effects. In particular, it appears to cause other valid files to appear in incorrect paths (read the OP’s post for more details on that, if interested).
If the NFS client of Windows is used, I am ready to move the blame towards Microsoft.
I have tested this with my NAS, and I was not impressed. It appears to have been tested only cursory.
