UMS won't launch

[Nadahar]

Actually, it's not as glib an answer is it sounds. The folder is created on the launch of UMS. I've changed the attributes, and I've deleted it outright. It gets created as a R.O. folder upon the launch of the software.

UMS creates the "UMS" part of the path yes, but not "R:\temp". It's strange that UMS has permissions to create a folder but not write to it, but in Windows permissions are inherited so it could be a problem with "R:\temp". What I still don't get is why that folder is used at all, so "UMS.conf" would be very interesting.

[Viridel]

UMS.conf attached.

R:\Temp is a windows-generated folder on bootup. Much in the same way as C:\Windows\Temp exists in a permanent state; with the RAMdrive, it obviously can't exist permanently, so it has to be re-generated on every boot. As far as Windows knows, R:\Temp is every bit as valid and usable as C:\Windows\Temp

[Galana]

attached

[Nadahar]

There's nothing special in your configs, so that means you must have tweaked the Windows configuration. UMS runs as the current user (unelevated), so that means that the folder must be writable for either "everyone", "users" or the specific users in question.

Since the drive is created at every startup, I'm wondering what software is doing this. C:\windows\temp isn't the normal temp folder user anymore, as that is only writable by administrators. That's why Windows usually assigns a temp folder within the user's "home" folder. I bet that if you check the permissions for "R:\temp" you will find that the "users" group does not have write permissions there.

[Nadahar]

The simple solution to get UMS running would then be to right click the UMS icon and select "run as administrator" - but it won't solve the underlying problem, the fact that UMS needs to be handed a writable folder structure by Windows.

[Viridel]

There's nothing special in your configs, so that means you must have tweaked the Windows configuration. UMS runs as the current user (unelevated), so that means that the folder must be writable for either "everyone", "users" or the specific users in question.

Since the drive is created at every startup, I'm wondering what software is doing this. C:\windows\temp isn't the normal temp folder user anymore, as that is only writable by administrators. That's why Windows usually assigns a temp folder within the user's "home" folder. I bet that if you check the permissions for "R:\temp" you will find that the "users" group does not have write permissions there.

And it is. There's only one usergroup in it, and it's "Everyone", and it has all check-options set for Allow (including Full Control).

Perhaps it would be easier to edit the UMS Config File to set up its own Temp somewhere else? What does UMS use its Temp for (hopefully not transcoding, which is the exact reason why the RAMdrive is such a powerful tool for media servers).

Two additional points:
a) running as Admin doesn't resolve the problem
b) v5.2x was running perfectly on her system, and 5.(something) was going great on my Win10 Tech Preview.

We've been running the same IMDisk RAMdrive system for I want to say 5+ years now, so the variable in this whole equation is the change from 5.2x to 5.3/5.4

**Hold your reply, I went to check your "Previous releases", and saw there's a 5.4 Java8 - we're both running 8.66 - your download link defaults to 5.4 Java7.

[Nadahar]

I don't have the full overview of what the temp folder is used for, but transcoding is a major part of it so moving it somewhere else probably isn't that interesting. What does the permissions on R:\temp\UMS say then?

[Nadahar]

I have an idea of the cause, at one stage probably between 5.2 and 5.3 we switched method for determining write permissions. Before that, the way it was done was to actually try to write a file and see if that succeeded, but now the permissions is read instead. I'm trying to figure out if the permissions being read fails for some reason, or if the permissions actually are wrong.

Can you create a file (new -> text file) in that folder? The fact that running as administrator didn't help is super strange. What filesystem is there on the ramdrive?

Downloading the Java8 version won't solve anything, it's the same code compiled for Java 7 and Java 8 only.

[Viridel]

I don't have the full overview of what the temp folder is used for, but transcoding is a major part of it so moving it somewhere else probably isn't that interesting. What does the permissions on R:\temp\UMS say then?

Permissions attached
ALL Drives on both systems are NTFS, and yeah, I can do whatever I want in the generated UMS folder.

[Nadahar]

Yes, the reason it's non changable is because it's inherited from the parent folder. I just have to figure out why the permissions are read wrong. I know it usually works fine on Windows 10, so what is different in this case?

Just as a shot in the dark - are you running 32 bit or 64 bit JVM?

Also, if you edit UMS.conf and adds a line you can specify the temp folder:

Code: Select all

temp_directory = <path>

I'm not saying that's a solution to the problem, but it will make it easy to try different locations and to actually get UMS started.