Administrator permission issues

[Weissrolf]

No permission were applied to the "Program Files\SmiteWorks\Fantasy Grounds" folder.

I will now uninstall, reinstall and then go right to the Dev channel to see what happens.

Edit: FGUpdater fails to uninstall (stuck at 12%) even after manually setting the permissions again. Steam did uninstall FGU itself, though. Will look into getting this to work and report back.

Edit2: After a simple logout/relogin FGUpdater was successfully uninstalled. I suspect that some part was still active when it kept crashing without proper permissions. On a side-note: FGUpdater is called "Fantasy Ground" (without Unity) in Windows' apps uninstall list, which makes is only discernible from Classic by its icon.

[Weissrolf]

Uninstall left the program files folder undeleted, so I have to manually delete it and try again. But I noticed a single log file in there with the following error text:

Uninstall desktop shortcut.
Uninstall Start menu shortcuts: C:\Users\myname\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\SmiteWorks\Fantasy Grounds
-Shortcut found, try delete
Clear uninstall registry entry.
Exception deleting reg key: System.Security.SecurityException: A security error has been detected.
at Microsoft.Win32.Win32RegistryApi.GenerateException (System.Int32 errorCode) [0x00045] in <fb001e01371b4adca20013e0ac763896>:0
at Microsoft.Win32.Win32RegistryApi.OpenSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyName, System.Boolean writable) [0x00038] in <fb001e01371b4adca20013e0ac763896>:0
at Microsoft.Win32.RegistryKey.OpenSubKey (System.String name, System.Boolean writable) [0x0001b] in <fb001e01371b4adca20013e0ac763896>:0
at (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey.OpenSubKey(string,bool )
at FantasyGrounds.Unity.Updater.View.fg_ui_updater.Un installShortcuts () [0x0008d] in <b7c85b62ad63402287369ebdc6744ebe>:0
OnApplicationQuit()
e: OnApplicationQuit - Could not find shell C:\Program Files\SmiteWorks\Fantasy Grounds\FantasyGroundsUpdater.exe To self-update!

[smelton]

To test the new build against your previous test scenario, manually add the permissions, launch the updater, change to Dev channel and run the update. After the update close it and remove the permissions. Relaunch the updater and it should prompt you to fix permissions. Hit the Fix Permissions button and this time it should wait until the permissions are applied. Afterward, the Users group should have full permissions on the application directory (I switch it to use the Users group instead of the Everyone group - not sure why the previous developer used the Everyone group in the first place).

This build also includes fixes for the uninstaller if you want to give that a test drive too I would appreciate it.

Note: when we do the release this week, a new installer that includes this build will be released so I'm no concerned with testing the current installer.

[Weissrolf]

I finished testing the DEV build. Little did I know that a new installation cannot switch to any build other than Live, so I first had to manually set permissions again to allow downloading the DEV build.

Once DEV installed I removed permissions to check how the DEV Updater handles things. It succeeded in setting permissions to both the Program Files and Data folder. Instead of allowing Write permissions to Everyone it set Full permissions to Users. I like the "Users" part, but wonder about the "Full" (instead of Write) part!?

This still is an unconventional and improper workaround, but it seems to be working better than before. It should save me the hassle of having to troubleshoot my players' setups. But again, a proper way of handling this would be for Updater to be restarted with Administrator rights whenever Program Files need to be updated.

[smelton]

There is an edge case, one that affects FGC (which works the "proper" way) that this design avoids. I think the biggest issue, which only affected Windows SL, was the permissions were being applied using the English spelling for the Users group. In this build, I changed that to apply permissions using the SID instead.

[Weissrolf]

I suspected that using English spelling might have been a possible issue. On the other hand I do use English on my desktop W10 (German on the laptop) and it still failed. Anyway, the new workaround is better now.

Symantec Antivirus did not keep FGU from setting the new permissions, after a restart I will check Windows Defender.

[Weissrolf]

Windows Defender does not keep FGU from changing permissions either.

FGUpdater can keep itself from setting its permissions, though. This happens when the "Fix Permissions" button is not hit fast enough. Updater then runs its course in the background and closes its own window before the button can be pressed.

[brionifi]

You said you reinstalled Windows 10 .. but that alone is a big change.. is this a fresh install from Microsoft media, or some OEM recovery image, which typically includes bloat software (including security software), provided by the PC manufacturer? Also note that not every user has full rights on every folder in the system; to prove that point, start notepad and try to save the file to the root c:\ path. I'm also curious, if your user account is an admin on the system, why did you have to explicitly add it to the FGU installation directory with write permissions when the Administrators group inherits Full Control on that directory?

As far as I know, the majority of our users do not have this permissions problem. The FGUWebInstaller adds the built-in Users group to the installation directory with write permissions as the last step of the installation process. We have tested this multiple times (i.e. both with/without the VC++ redistributable preinstalled) on a VM with a fresh Windows 10 installation and I have confirmed the group is there post-install. Note: we use the Users group because we can't assume that every one of our users is the only user and/or is an admin on their PC. If that group is not listed under the security tab of the installation directory then something on your system must have removed it.

I agree, the user shouldn't be required to manually adjust user rights. Believe me, this is not the initial experience we want our users to have. However, if security software is running that is going to tamper with an application's installation, and the installation doesn't function properly, then manual intervention may be required. We try to prevent this by including a feature in the updater that detects and attempts to fix the missing permissions; but again, if the security software is aggressively enforcing its policies it either prevents us from adding the permissions required (in which case you see a "Failed to fix permissions" error), or we succeed and start the update process which fails because the security software immediately removed the permissions. "Disabling" the security software can mean something depending on software used, so the best solution is to add a rule to it to exclude the FGU installation directory and try again.

I Bought the FGU but becouse of this problem i keep playing with the FGC , all my friends have the permission problem and i dont now how to fix it
i'm a brasilian so sry for the bad english

[smelton]

If you are still having this issue my guess is you are using an old installer. Download the latest installer (https://www.fantasygrounds.com/filel...WebInstall.exe) and try again

[rgtschope]

I Bought the FGU but becouse of this problem i keep playing with the FGC , all my friends have the permission problem and i dont now how to fix it
i'm a brasilian so sry for the bad english

As permissões em Windows SLE são estranhas, então você precisa manualmente colocar as permissões para as pastas, até mesmo a padrão do FGU. Acredito que a opção de Consertar Persmissões no FGU não leva em conta sistemas com idiomas diferentes e o esquema diferente das permissões SLE. De qualquer jeito, segue um tutorial básico em como consertar manualmente isso. CUIDADO: Siga EXATAMENTE como escrito e por favor note que bagunçar as permissões erradas das pastas pode levar a crashes extremos do Windows.

1)Vá para a pasta de instalação e clique com o botão direito.
2)Clique em Propriedades.
3)Vá para a aba de Segurança
4)Clique em Editar (uma nova janela aparece)
5)Clique em Adicionar (uma wild new janela aparece)
6)Clique em Avançado (ei! outra janela!)
7)Clique em Procurar Agora(ou algo parecido com isso)
8)Um punhado de nomes deve aparecer na parte debaixo dessa janela.
9)Dê um clique duplo no nome que tem o seu nome de usuário (nome de login, conta de email, qualquer que seja seu método de logar no Windows)
10)Deve voltar para a janela anterior. Clique OK nela.
11)Deve voltar para a janela anterior. Lá, selecione o usuário recém adicionado e nas permissões abaixo (que já deve estar selecionado, mas confere), seleciona a caixa Permitir Controle Total. Aperte Aplicar e então OK.
12)Clique OK em quaisquer outras janelas e repita o processo para o diretório Data do FGU.
13)Reinstale ou Re-atualize o FGU (com cuidado para selecionar as pastas que você alterou quando pedir as pastas de instalação e de dados.
14)???
15)Lucro!

É isso! O processo deve ser o mesmo para Wuindows 10 e 8 (o FGU não é compatível com o 7). De todas as pessoas que eu já fiz esse método (umas 8), 7 funcionaram, mas uma delas não seguiu os passos EXATAMENTE e deletou o acesso a todos os arquivos dele no HD, deixando o sistema dele inutilizável. Então tenha cuidado!

Como o Dev respondeu na resposta seguinte a essa, a versão nova do instalador já atualizou os problemas de permissão do Windows SLE, então antes de tentar esses passos, peça para a galera baixar o novo instalador no https://www.fantasygrounds.com/filel...WebInstall.exe

Boa sorte!