Folding Forum

Thanks, @aka_daryl. If you want to share what you come up with, I'm sure there would be people here who would benefit from it.

I have this problem too. Installed in my non-administrative account which is the account I normally use. Ran like a top until I restarted my computer. Folding failed to autostart after I rebooted. Was unsuccessful in copying a bookmark from an administrative account to my non-administrative account. Uninstalled. Custom installed, guiding the program to install in the non-administrative account. Would not autostart after reboot and bookmarks on the Desktop disabled.

Hi guys, yes I 100% will, we have a workaround with our QC team at the moment and are looking at deployment tomorrow so I will keep you posted

lumpy wrote:I cannot start it from bik. It will start automatically if I log into my admin account, but since I don't want to do that on a regular basis it's not running at all. There is a shortcut if I log into the admin account.

At some point, you installed FAH from the admin account and you have not removed it.

When you install from the account blk, it will create a shorcut that starts it when blk logs on. Use that shortcut to start it manually. If you selected start automatically, that shortcut will be run and data files will be placed in a hidden directory that belongs to blk (Because of the envirnment variable set during the install. Note that the most recent log above shows

14:27:33: Config: C:\Users\usr\AppData\Roaming\FAHClient\config.xml
and
14:27:33: CWD: C:\Users\usr\AppData\Roaming\FAHClient
rather than
Config: C:\Users\blk\AppData\Roaming\FAHClient\config.xml
and
CWD: C:\Users\blk\AppData\Roaming\FAHClient

Maybe you're simply using the wrong shortcut. The account for "usr" is not the account for "blk"

hey all,

the script we created to install F@H in a multi-user environment can be found on my git hub at https://github.com/dtitco69/FAH_tools the script is called FAH_Multiuser.bat and is designed to allow an admin to install F@H from a network drive and install a pregened config file.

the first few lines will need customizing to the location you have the file stored, in the script I have uploaded they point to the latest version of the installer on our deployment server but could be changed to something like this for a local install
as you will most likely also not be using a custom config file I would recommend commenting out the lines that copy the config file like so
The deployment team at work are now interested in this project and have asked to spend some time creating an MSI that has all these features for group policy deployment on a domain but due to the current circumstances they are flat out and not able to donate as much time as they would like but if this gets anywhere I will be sure to host the file we create

Hope this helps someone and feel free to message and/or contribute with improvements and further ideas

The vast majority of Windows users will be installing this from a normal user account and supplying admin privileges upon running the installer. The installer itself needs to handle this properly just like every other software installer out there. I'm not running special scripts to install this on a vanilla windows installation. It's just not happening.

russ1642 wrote:The vast majority of Windows users will be installing this from a normal user account and supplying admin privileges upon running the installer. The installer itself needs to handle this properly just like every other software installer out there. I'm not running special scripts to install this on a vanilla windows installation. It's just not happening.

If you have two accounts on the system, such as a regular account and an admin account, you can log into the admin account and F@h should start up. You can also click the icon on the desktop or through the Start Menu. Since the installer runs with admin rights, it will set these up to the admin user, but I agree that ideally it should also install a link on the normal user's desktop and Start Menu. Most Windows users don't encounter this problem because they typically have a single account that can get admin rights, and thus everything setup for the admin are also going to work for the unprivileged user, since they are the same account.

Hi all, yes this is not ideal however the script gets around this issue, F@H should indeed install in multi-user mode but this is not how it is currently set up as such if there is more than one account on the PC you will either: need to do all the copying of files and ensuring that directories are set up correctly manually or use a script to do this for you, all im doing is providing a tool that we developed to allow us to deploy easier to multi-user setups, it's up to you if you want to use it

Exactly the same problem here!
With win10 installation there is definetely a problem!

Win10pro, up-to-date 25.03.2020;
two seperate accounts ADMIN (admin, for admin-purpose only) and WORK (regular user, for working)
fah-installer_7.5.1_x86.exe downloaded from folding@home homepage.

First install done logged in as WORK, clean standard installation, admin-confirmation asked and given during installation. No playing around with settings.
first autostart FAH worked fine.

After shutdown and restart however, nothing worked, no icons, no resume of interrupted work,
appearantly, appdata is by default stored in wrong folder c:/user/ADMIN/appdata/roaming/FaH - instead of c:/user/WORK/appdata/roaming/FaH
WORK should't even have access to c:/user/ADMIN/.. !!!
no wonder neither FaH-autostart works, nor resume works.
maybe not only installation is done with admin-permission, but also first run of FAH as admin-user instead of logged in WORK user?

tried reinstall with custom settings + manual location path c:/user/WORK/appdata/roaming/FaH
does not work properly, no Icons, no autostart
manual start of FaH-client works though, but not properly (runs as app instead of background service) and gets stuck.

(lost 4 WU by now - without corona quarantaine and lot's of time I would have given up by now...)


found WORKAROUND:

- deinstall + manual deleting of all directories and data (C:/Progs(x86)/FaH, C:/aser/ADMIN/appdata/roaming/FaH)
- temporarily change type of user "WORK" to full rights admin-account
- (reboot)
- install FaH
- autorun FaH as WORK (with admin-rights) once
- reboot
- login as "ADMIN", activate access permission for user ADMIN to folder c:/user/WORK/appdata/roaming/FaH
- change type of WORK user account to regular user as before.
- reboot
--> FaH now works for both ADMIN and WORK on startup, autostart and resume!

Hopefully this may help to find the bug.

Hi mik5

The issue is how the installer has been built, it stores the data in the appdata not the programdata folder, this can be rectified in the install progress using custom install

The second issue is the auto start is setup in the local users start menu startup folder, this needs moving to the public start menu folder to allow all users to autostart, I will be happy to go over the issue with you in more detail if you want?

Hi aka_daryl

Many thanks for you offer, after my workaround solution FaH is folding smooth now and I won't change it again.
I rather posted it so the workaround may help whoever searches may finds it.

However it seems the installer doesn't work properly in standard install in a Win10 setup when installed + run by a regular user just giving admin-confirmation.
In this setup standard install chooses the appdata folder of the wrong user (admin) to which the regular user has no more access after restart!
At least there should be an explanation during install process.

Maybe you can forward this issue to the developement crew as a topic - I do not really know who to contact.

: -) mik5

Here is my workaround to get FAH client to run correctly under a standard, non-admin Win10 account (with GPU support):

viewtopic.php?f=106&t=33531

This is absolutely still a problem. I just upgraded from Win 7 to 10 and f@h didn't make it across. Reinstalling I wasn't even offered the choice as to install for 'just me' or 'everyone'. It installed to the admin account only, which I solved by manually copying the folders from the admin Start Menu and Start Up, and the data in AppData\Roaming then changing all the references for 'Start in' to the non-admin user.