Feature Request: Support for network paths

[petenun]

I have a distributed Windows network with front-end application servers (such as Plex and Subsonic) connected to media located on a different dedicated file server, all with a 10GBE network backbone. I'm running ABS as a Windows service (which works flawlessly) under a service account with access to network file locations). The problem is that I haven't been able to move ABS to my front-end server since I have not yet found a way to point ABS to media on a different server.

Though it's difficult to utilize drive mapping since mappings can differ for each logged-in user, I'd love to see UNC pathing (e.g. \server\share\path) incorporated into ABS. Since UNC pathing is a constant, unlike mapped drives, it should be feasible in theory. I use the same kind of pathing for application such as Subsonic, Sonarr, and Radarr. Would this be a possibility to add to a future release?

And BTW, this is an incredibly valuable Windows port. Thank you very much for your continued work on this project!!

[mikiher]

Hey, sorry for answering late.

So you're saying you're able to access some file server through a UNC address in Windows, but are not able to access it in Audiobookshelf?
If you map it to a drive, is Audiobookshelf able to then access it? If that is the case, can you please open a bug and share the details?

I have an SMB network folder mapped to drive Z: on my Windows system, and I have no issues accessing it with Audiobookshelf through the drive letter. Also, the drive letter never seems to change.

[petenun]

To answer your initial question, yes, ABS does work with network drive mappings, provided you're logged-in with the same user account all the time.

Drive mappings change depending on who's logged in to Windows, and are mapped upon login. In my case, I'm running ABS as a Windows service so it'll run automatically on start-up, even if nobody is actively logged in, which means drives are not yet mapped. This is where UNC pathing would be helpful. UNCs work independent of user accounts, and will connect with the permissions of the account under which you're running the service.

Does that make sense?

[mikiher]

Yes, thank you. I think I have an idea why UNC paths might not work. Stay tuned...

[mikiher]

Discussion #21 is reporting the same issue. I closed that discussion and moved it over here.

[mikiher]

Also, this bug (and it is definitely a bug in my opinion - it should just work) was reported a long time ago on the server (UNC Path adds drive letter), and wasn't fixed. This is a server bug, so I will continue analysis and fix over there. Thanks for bringing this up!

[petenun]

Let me know if I can do anything to assist or test on my side.

[mikiher]

Submitted server PR #3254 to fix this.

[mikiher]

This should be resolved in release v2.12.2. Please update and let me know if you encounter additional issues.

[petenun]

I just applied the update and it works like a champ. The only weird thing is that the path to the library looks like this "\\server/share/Media/Books/AudioBooks", where the path begins with backslashes, but everything else are forward slashes. It's just different from the normal Windows syntax, BUT it works, so I'm not complaining. Thank you so much for the fast turn-around on this. You rock! 😊

[mikiher]

For various reasons, Audiobookshelf performs posix path normalization on all paths (essentially replacing all backslahes to slashes), so seeing paths like \\server/share/Media/Books/AudioBooks is expected. The fix was to actually preserve the \\ and not normalize it to //, since this messed up UNC path semantics, and caused all the issues you saw.