VirtualFolders.conf and Network-drives (mapped or unmapped) (Windows 8.1 64bit)

[PaJson]

I have used UMS for a long time, since it's predecessor PMS. After installing a new computer last year I have been using newer Java7-versions of UMS, 6.5.x and now the 7.0.0-a1.

My problem is using Network-shares inside UMS. It works well when I add them under the tab "Navigation/Share-Settings" inside UMS, but not when I add them to VirtualFolders.conf. It doesn't matter if I use the network-path or if I map the drives/paths and use the mapped folder letter (in this case X:). All UMS does is give me a WARN and tells me it "Can't read folder:". I have included a ums_dbg.zip with the problem traced/debugged.

Since I guess it also requires the VirtualFolders.conf, I added that manually to the .zip, since there is also a bug with the "Pack debug files"-options. The V in VirtualFolders.conf is missing, so it is looking for irtualFolders.conf. See attached screenshot (and log).

Thanks for a wonderful application and keep up the good work!

[Nadahar]

Thank you for your report.

The missing first letter in DbgPacker was definitly a bug, it will be fixed in the next version.

Your real problem isn't that obvious to me. I tested this, both using a mapped drive letter and UNC path - and it's working for me. I also looked at the code, and the log message is a bit wague - the real reason is that UMS has insufficient permission to read the folder. I've compiled an updated version where the log message is a bit more specific. It would be nice if you could test with this version and report back what the log says.

If we assume that it's not a bug and that the permission really is insufficient, it's very strange that it works if you add the same folders as shared folders. It's also strange that it just works for me. Are you running UMS as a service? Can you try to give "everybody" read permission on the share (both on the share itself and on the file permission of the folder) so that we can see if that makes a difference?

Here is the updated version.

[PaJson]

Sorry for the late reply, but I found some time this morning to test it out.

It seems to be a difference when sharing or accessing a drive compared to a folder.
When editing permissions on the client-side (where UMS is running) this is what I got:
I tried to apply read/write/run permissions for the group "Everyone" on the network-path for the entire shared drive, which Windows didn't allow me to do.
I then tried to apply read/write/run permissions for the group "Everyone" on a sub-folder (i.e. Movies, Series, ...) on the network-path of the mapped drive, and that Windows did allow me to do.
After that it works with VirtualFolders.conf!
(The settings on the server-side wasn't changed, and has always been set to full permissions!)


But I am still confused as to why it works when putting the the same path/folder inside the GUI for the tab "Navigation/Share-Settings" inside UMS and not in VirtualFolders.conf. Does UMS use different credentials (user permissions) when applying different settings for UMS? i.e. Does UMS use my logged in credentials when mapping the tab "Navigation/Share-Settings" and does it try to use other credentials (group Everyone) when mapping the VirtualFolders.conf? Anyway, I now have a workaround, and at the moment it's just a few sub-folders that are of interest so it's not much I need to fix. But I still think it should have worked "as is".

Side note: Not sure if Version 7.0.0-a1 has a memory leak, but after a week or so I can't get into the apps GUI from the systray-icon or in any other way, forcing me to kill the process and restart it. Or maybe it was because the network-drivers were temporarily removed for a few hours, but that should only have made UMS drop the mapping, not hang itself?

[Sami32]

@PaJson

How @Nadahar already told, that's work for us, so if you want that also work for you, just follow his advice and post a new log with the special UMS version done for you.

BTW, thanks to @Nadahar for helped you on his free time...