Version 4.8.10 drops windows mount points.

[lmnau 0]

Hi
anyone have the same problem? My movies are mounted on my windows Emby Server box as a mount point at M:\ all my other media is on local drive D:\ . Since the update, Emby doesn't see the M:\ drive designation. It can perfectly see the NAS that hosts the /Movies directory under [Network], and I can add that as a folder and get everything to work, but why has it suddenly dropped "non-local" drives.

Luke

[Luke 42079]

Hi, this will have nothing to do with the Emby server update. Make sure windows explorer can see those mounts and then you should be good to go.

 This is actually the very reason that we recommend using the original network paths rather than mapped drives when possible. Windows will often disconnect mapped drives when idle.

[lmnau 0]

Of course windows can see the mount point. When you go into [add] folder to library, the C,D drives are there, none of my other mount points are there.

It was working before the update, then all my movies errored, but all my other media was fine. went in to configure the library and this is when I found the issue.

[Gilgamesh_48 1240]

13 minutes ago, lmnau said:

Of course windows can see the mount point. When you go into [add] folder to library, the C,D drives are there, none of my other mount points are there.

It was working before the update, then all my movies errored, but all my other media was fine. went in to configure the library and this is when I found the issue.

Reboot the computers? (server and drive source) That always fixes problems with network storage for me. At least almost always. Sometimes i also have to restart my network, but that has not been needed for a tear or more. 

[rbjtech 5284]

I've always used UNC share's - even on local file systems - as they provide the maximum flexibility and are 100% reliable.  Using drive letters is outdated and leads to issues when you add drives etc (you need to remap all the drives manually).   

ie create a share for your m:  for example  '\\servername\sharename' .    The bonus is you can change the actual mount point (if you move to drive pooling, add a bigger drive or whatever) and as long as you keep the UNC sharename the same, then emby won't care and doesn't need to change. 

To note, any local 'share' will not go through the network stack, as Windows is intelligent enough to know it's local.

Edited October 13, 2024 by rbjtech

[lmnau 0]

Yeah, but it was working. Now it's not.

Using map drives is not out of date (windows). it solves the problem of changing target sources on services, like Emby. If I want to move the data to a different server, just changing the M:/ mount point changes all services, rather than going into each service and changing the \\server\directory.... this happens a lot in backup targets. Often have to move Veeam backups and rather than re-configuring each task, I can just change the mount point target. Your method implies a complete transplant of the server, which we can't do in commercial environments where data needs to remain live, so it gets the next \\server2 name... you get the idea. Now given that this a home NAS || Server relation, I've got 3 NAS running all windows ReFS, because slow as it is, its stable, and doesn't eat file like NTFS does. And its faster than ZFS. So I don't need to be told about shares and services, everything is working fine.

Fine to the point that I could go into the add, and yes, add Network>NAS>Directory, and it's all back.

I get the local share thing, but I don't get your point, because the D:\ is local but is shared, but Emby isn't attaching to it through network, and we going to [add] it can see C:\ and D:\ , so I can add D:\subdirectory\ to the library no problem.... but I also had M:\subdirectory\ and it was working perfectly, and now it disappeared, and the option disappeared. I've also check with other mount points on other servers.

[Happy2Play 9780]

99% of the time it will come back to a Windows issues not a Emby issue as I have many programs that have dumped mapped drives over time and it is not the programs fault Windows is causing the issue.

 

All the devs usually come back with the same as posted above as it is a well-known Windows issue.

Edited October 13, 2024 by Happy2Play

[Carlo 4561]

Totally agree from proving support over the years on this using Windows.

Drop the drive mapping and use UNC naming.
One giant headache later, you'll be glad you switched!

Carlo

[Luke 42079]

@lmnau please let us know if this helps. Thanks.