Folding Forum

I am in this same situation. I am a returning F@H contributer and I'm installing onto a new machine. Also Win10 with a non-admin user account. Installing as the user, but it picks a directory in the admin's account for data. Even if I change that to my user during the install process, it doesn't not work. I did not set it to automatically start. There is no icon on my desktop. There is nothing in the start menu. I ran it manually from the program files directory and it can't execute work units. This may be a complication from the install issues, so I'll hold off on filing that as an issue until the install part is fixed.

Please let us know what you find.

The default Windows installation is set for "just for me" and files are placed in a private directory. It assumes the userid that's going to be logged on when FAH is run is the same person doing the installation. The option to run "for everyone" probably caused your problem.

The "everyone" option was probably based on a misreading of Microsoft documentation. They don't really have a suitable method of enabling everyone to run WUs in shared working files. It has never worked.

I will check that. Thank you for the suggestion.

That did it. Literally the only different is selecting the automatic config instead of the manual--even when changing no settings on the manual.

No, that's not the only difference. FAH creates it's working files in %APPDATA% per Microsoft's recommendations. The value assigned to the environment variable %APPDATA% depends on the user that's logged on except when you select "For Everyone"

Okay, after a reboot, it no longer starts nor can I seem to run it. There's no start menu entry. If I go to the program install dir and run it, I get the old "cannot access" type of errors.

Suggestions?

willmore wrote:Okay, after a reboot, it no longer starts nor can I seem to run it. There's no start menu entry. If I go to the program install dir and run it, I get the old "cannot access" type of errors.

Suggestions?

Unfortunately, it doesn't look like the current installer works with windows and a non-admin account.

When you supply an admin account to install, the installer runs as the admin user, so it's %APPDATA% becomes theirs, not the logged in users. You can manually change the data directory, but it looks like other files and paths don't follow properly.

rwh202 wrote:Unfortunately, it doesn't look like the current installer works with windows and a non-admin account.

When you supply an admin account to install, the installer runs as the admin user, so it's %APPDATA% becomes theirs, not the logged in users. You can manually change the data directory, but it looks like other files and paths don't follow properly.

That is correct. I have tried doing a custom install and changing the username portion of the path to my user and that failed with these same errors.

The question I have is why did it work on the first install? I have tried 'run as administrator' and that failed as well with similar errors.

Since current best practices is not to run as the admin user unless doing system maintenance, it would seem imperative to fix the F@H installer and programs to function properly in that configuration.

willmore wrote:The question I have is why did it work on the first install? I have tried 'run as administrator' and that failed as well with similar errors.

I've tried on a spare windows 10 pc and by doing a default install under a normal user and selecting 'start folding@home' at the end, it does run, but as the admin user.
When you restart, it's no longer able to run.

One has to think this is a solved problem in the Windows installer world, no?

willmore wrote:One has to think this is a solved problem in the Windows installer world, no?

Yes, but there appears to be very limited software developer support for the folding project.

A quick google of 'windows installer admin appdata' returns plenty of hits - including Appdata files going to admin's appdata instead of standard user which looks very similar to what's happening here, together with a few work arounds for the developer to try.

Good find. I wonder if it's an issue of %APP_DATA% being evaluated at the wrong time. Looks like it's getting evaluated at install time instead of runtime. I don't speak Windows scripting, but in the Unix world it would be a matter of escaping the % marks.

It's still possible to do a dirty manual installation ...

toTOW wrote:It's still possible to do a dirty manual installation ...

How does one go about that? Extract all the files, stuff them somewhere conveneient and run the binaries manually and hope for the best?

this is normal procedure for UAC, that's why a lot of apps say install for everyone or install for just me, we are looking at a domain-wide deployment and are probably going to have to script it so that we can work around the UAC/appdata issue by changing the datapath to "c:\ProgramData\FAH\" to allow all system users access to it, we still haven't looked at getting it to autostart with every user and not just the admin