I installed O-drive as standard user on a Win10 machine. The UAC prompts comes up as expected and everything appears to install fine… right up until the program launches. I get a message “Location is not available” (which that could be shortened to “unavailable”). It then points to the default admin folder location: C:\Users<admin acct>\odrive (access is denied).
Luckily I’m nosy and read a few open reports in the forum before writing up topic. It appears there’s a “move” feature that should be able to resolve my problem.
- When this particular error occurs you should at that point suggest (or require) the user to change their storage path by giving them a folder prompt.
- You should be detecting if users are on a Windows environment and changing the install location for non-admin users. Other established apps tend to direct to %localappdata%<app name> for these instances. This folder location location should be the default selection when the user is non-admin (even if they are attempting an all-user installation.
- Three things. I lied. During installation gives us 3 install options: all users, per user/current user, portable.
If you launch odrive from a shortcut, or from C:\Program Files\odrive\odrive.exe it should setup odrive for that particular user. It will actually install the binaries in the user’s profile directory (
%userprofile%\.odrive), if it doesn’t already exist there and then run the binaries from there, which should have no permissions issues. Once you login the
%userprofile%\odrive folder will be created.
Can you try exiting any running odrive processes and then running odrive again as your current user and see what the behavior is?
There was no need for me to redo the install. The app wouldn’t work after the initial install. However once I moved it (the odrive folder) then rebooted my machine I was prompted by another instance of the app re-initializing itself to the non-admin account. It appears to be working just fine albeit I’m not well versed with your program to say it’s 100% functional.
I’ll uninstall it, retry your suggestion, and post an update.
It sounds like the reboot initiated the app running under your account.
I think what probably happened is it was installed as an administrator account, so the app launched under that user after install. The reboot essentially did what I was suggesting which was re-launching as your non-administrator user.
You should be fine now and most likely do not need to try an uninstall and reinstall.
I attempted to duplicate the problem again by uninstalling. The error recurred but this time after the reboot the install didn’t reinitialize. This I’m guessing is due the previous install settings and registry entries already existing. I couldn’t say with any certainty whether the reboot alone help to resolve the problem or if moving the folder then rebooting fixed it. A clean virtual environment would be necessary for retesting.
Moving along. I ran into another problem with unsync. However I’ll look the User Guide once over again to confirm expected behavior before writing a separate issue.
For clarity on what odrive is doing:
odrive installs a “loader” application into
C:\Program Files. This loader will install the actual app binaries into the user’s profile directory, under the
.odrive folder and then run the app from there. If the files have already been installed there then it just runs them.
If the installer is run as a different user then it will end up running the loader as that user, which will install and run the app binaries from that user, also, since it is all spawned from the privileged account. This will create the initial situation where the app loads up under the installer’s environment rather than the logged-in user’s environment. If the app is exited and then started again, the loader will now be running as the non-privileged user and behave as expected.
On uninstall the same permissions funkiness can happen, where the uninstall will remove the loader from C:\Program Files and from the running user’s profile directory. This is why you didn’t see a change for the non-admin user after uninstall and reinstall, because the app was still present in their user profile directory. There is a shell script that can be run by the non-admin current user that can clean up the “localized” files. You can find this at
C:\Users\[user name here]\.odrive\common\bin\CU_Uninstall.ps1
This is probably more detail than you wanted, but I just wanted to try to explain the behavior you are seeing.
Definitely let me know if you are seeing any issues with unsync, or have any questions.