5E Product Walkthrough Playlist
Page 8 of 8 First ... 678
  1. #71

    Latest installer has terrible permissions/paths

    I just downloaded the Free Client for FGU to join a D&D campaign being hosted by a FGU Ultimate subscriber. For the installer, it says "v4.0.0 (2020-11-09)"

    I just went through the defaults and let it install where it felt it needed to install.
    1) First gripe: User applications should never EVER need administrative privileges. EVER. As a former admin, this is just a huge security hole that should never ever be used. EVER. Yes, it allows for some easy updates and installations, but it is entirely unnecessary. Ok, I think I've made my point. :P

    2) While using FGU, everything worked, except when I tried to plug in a portrait for my character. The directory it needed, "<USER acct>/AppData/Roaming/SmiteWorks/Fantasy Grounds/portraits" did not exist. That's because I have created a non-admin account on my windows box (like everyone should) and use that as my primary account (because no one should be using an admin account as their day-to-day account). I went digging around and found that the path FGU had created was "<ADMIN acct>/AppData/Roaming/SmiteWorks/Fantasy Grounds/...". This doesn't make sense to me. I am installing the app as a USER, I want the data and all of the objects to be installed in my USER directory, not the ADMIN directory. I manually created the USER/.../portraits directory, uploaded my file, and could then use it. But that should never have been necessary. Note, at this point, I had used all of the defaults for everything FGU asked for during installation.

    3) I uninstalled and reinstalled, this time pointing the data directory to my USER directory, but then when I connected to the campaign, there was no data. The PHB window would open up blank, the Items window would open up blank, essentially it looked like none of the components had been installed. I believe this is because I had pointed the installer to use "USER/.../Fantasy Grounds" instead of allowing it to install data into "ADMIN/.../Fantasy Grounds", which is the default it wanted.

    4) Three hours later, after uninstalling/reinstalling(and rinse-repeat), registry editing, manually deleting folders, reboot, I tried again, letting FGU use all of the defaults. No desktop icon was created. If I click on the folder icon in the top left of the main FGU window, it once again says "USER/.../Fantasy Grounds" doesn't exist.

    Extremely frustrating.

  2. #72
    When you are using a non admin user and FGU then asks for administrator rights to do its installation then for the time of the installation said administrator account *is* the user. This explains why the folder creation stuff goes south. It should not happen, but that's how it likely is.

    I keep repeating this: FGU's installer and updater should only ask for administrator rights when they need to write/update files to "\Program Files". Data files should not be written via administrator account, which they don't need anyway. This is how Windows software works for years already, please follow the proper procedures.

  3. #73
    Zacchaeus's Avatar
    Join Date
    Dec 2014
    Location
    Scotland
    Posts
    16,432
    If you accepted the default installation then the data should have installed into users/username/Appdata etc

    I suspect because you've done something non standard (I don't know what a non admin account is and I doubt many others do either) then I suspect that you should have pointed the installation to there rather than the default if that's where you wanted the data to go. Whatever the case FGU needs the correct permissions in order to save files to the FGData folder.
    If you need to contact customer support or if there is something that you would like to see in Fantasy Grounds that isn't currently part of the software or if there is something you think would improve a ruleset then add your idea here http://fgapp.idea.informer.com/

  4. #74
    On Windows, OS X and Linux there are "Standard" or "User" accounts and there are "Administrator" accounts. When you are using a standard account then software that needs elevated rights asks for the login name and password of an administrator accoun. On Windows you need elevated rights to write to "/Program Files/" for good reasons. No elevation rights are needed to write to a users own "Users/User/" directory and it is not needed for FGU to change any permissions there.

    Problem in Windows is: When a software installation asks for elevated rights through an administrator account then the software effectively runs under this account. At that moment "users/username/" is not the name of the original account anymore, but the name of the administrator account. This also comes with other drawbacks, like network drive letter mappings only being valid per account (so User may have drive H: mapped, but Administrator may not).

    Again: FGU's user data should never have to be installed/updated using administrator rights to begin with, it's completely unnecessary and creates additional problems and security issues. It's bad practice and not how any other software on my computer handles these kind of things. Developers had time since Windows Vista to learn this.

    Happy holidays.
    Last edited by Weissrolf; December 25th, 2020 at 09:58.

  5. #75
    Quote Originally Posted by Weissrolf View Post
    On Windows, OS X and Linux there are "Standard" or "User" accounts and there are "Administrator" accounts. When you are using a standard account then software that needs elevated rights asks for the login name and password of an administrator accoun. On Windows you need elevated rights to write to "/Program Files/" for good reasons. No elevation rights are needed to write to a users own "Users/User/" directory and it is not needed for FGU to change any permissions there.

    Problem in Windows is: When a software installation asks for elevated rights through an administrator account then the software effectively runs under this account. At that moment "users/username/" is not the name of the original account anymore, but the name of the administrator account. This also comes with other drawbacks, like network drive letter mappings only being valid per account (so User may have drive H: mapped, but Administrator may not).

    Again: FGU's user data should never have to be installed/updated using administrator rights to begin with, it's completely unnecessary and creates additional problems and security issues. It's bad practice and not how any other software on my computer handles these kind of things. Developers had time since Windows Vista to learn this.

    Happy holidays.
    I guess we have to create campaigns and play on our administrator account. From what I understand installing/updating/DMing/playing on a non-admin account doesn't save the changes? I am confused by this as I like to use separate accounts for business (admin. acct.) and recreation (non-admin acct). Is it true that changing the default file path to the desired /user/account will result in having to verify credentials every time?
    Please correct me if I'm wrong. I am confused.

  6. #76
    No, the data is saved in another folder from the software. And the current installer sets user rights to both folders at least in a better way than the old installer did. So you can use a non admin account as long as the folder rights process done by the installer works as expected.

  7. #77
    I'm running Mac OS Big Sur 11.2.3 and had multiple problems. Installation would hang without opening the updater. Once I fixed the updater issue, it kept telling me that Fantasy Grounds didn't have read or write permissions in the directory, and the Fix Permissions button didn't work. I did finally manage to get everything to work, but I'm not entirely sure which step got the Updater working and I'm a little afraid to mess with it. I reproduce those steps here, and maybe someone braver than I can experiment, or someone with more Mac experience (I've only had mine a couple of months), can explain to me whether what I've found actually means anything.

    1). Installation proceeded smoothly but would not permit me to install anywhere other than the Applications folder. I found this annoying as my Mac has limited hard drive space.
    2). Got to the end screen where it says, "The updater will now run." Heard a beep, as if an application was being blocked, but nothing opened. A glance into System Preferences: Security & Privacy: General lists nothing to indicate an app was blocked.
    3). Tried running Applications: Smiteworks: Fantasy Grounds: FantasyGroundsUpdater and had the same issue as everyone else - small window flashes and closes. Nothing else happens. Found the thread here that said to use the FGUpdaterEngine instead. Did that and finally got the updater to start.
    4). Go through the login and licensing process, change the folder to the external drive where I want data to be stored. Get an error saying FGU cannot write to the Applications or Data directories. Try the "Fix Permissions" button. Nothing happens. Close the updater. Try again. Same results.
    5). Lots of digging on the Mac and Smiteworks forums. Lots of aggravation and cursing. Can't get permissions to change in the Security window because the only option available under Privacy: Files and Folders: FGUpdaterEngine is "Removable Volumes" which is checked. No other files or folders show up there to allow access. Can not seem to manually fix the error.
    6). More digging. Decide to check permissions on the FGUpdater Engine itself, by going to Get Info, all the way down to Sharing & Permissions. Strange - *I* have the ability to read & write, but admin only has read ability. Shouldn't the admin account have read *and* write ability? This is where I'm not sure if I'm understanding things correctly. I change permissions for admin, giving them read & write, close Get Info and try again.
    7). Unfortunately, I clicked through without meaning to, and wound up installing to the default directory instead of the external where I wanted.
    8). Upgrade was completely successful. FG opened correctly.

    So - sorry about the length of this, but I'm not sure if my fixing permissions on the updater itself is what fixed the problem, and if that means I would have been able to update and download to the external as I wanted, or if those permission settings have nothing to do with it. Either way, I'm hoping someone can answer a couple of basic Mac questions regarding this incident, and that what I did here gives someone else with the same problem a bit of hope.
    Art, Games, Life
    www.netjera.com (In progress, so be kind, please)

  8. #78
    smelton's Avatar
    Join Date
    Jul 2016
    Location
    Plano, TX
    Posts
    217
    Quote Originally Posted by Netjera View Post
    I'm running Mac OS Big Sur 11.2.3 and had multiple problems. Installation would hang without opening the updater. Once I fixed the updater issue, it kept telling me that Fantasy Grounds didn't have read or write permissions in the directory, and the Fix Permissions button didn't work. I did finally manage to get everything to work, but I'm not entirely sure which step got the Updater working and I'm a little afraid to mess with it. I reproduce those steps here, and maybe someone braver than I can experiment, or someone with more Mac experience (I've only had mine a couple of months), can explain to me whether what I've found actually means anything.

    1). Installation proceeded smoothly but would not permit me to install anywhere other than the Applications folder. I found this annoying as my Mac has limited hard drive space.
    2). Got to the end screen where it says, "The updater will now run." Heard a beep, as if an application was being blocked, but nothing opened. A glance into System Preferences: Security & Privacy: General lists nothing to indicate an app was blocked.
    3). Tried running Applications: Smiteworks: Fantasy Grounds: FantasyGroundsUpdater and had the same issue as everyone else - small window flashes and closes. Nothing else happens. Found the thread here that said to use the FGUpdaterEngine instead. Did that and finally got the updater to start.
    4). Go through the login and licensing process, change the folder to the external drive where I want data to be stored. Get an error saying FGU cannot write to the Applications or Data directories. Try the "Fix Permissions" button. Nothing happens. Close the updater. Try again. Same results.
    5). Lots of digging on the Mac and Smiteworks forums. Lots of aggravation and cursing. Can't get permissions to change in the Security window because the only option available under Privacy: Files and Folders: FGUpdaterEngine is "Removable Volumes" which is checked. No other files or folders show up there to allow access. Can not seem to manually fix the error.
    6). More digging. Decide to check permissions on the FGUpdater Engine itself, by going to Get Info, all the way down to Sharing & Permissions. Strange - *I* have the ability to read & write, but admin only has read ability. Shouldn't the admin account have read *and* write ability? This is where I'm not sure if I'm understanding things correctly. I change permissions for admin, giving them read & write, close Get Info and try again.
    7). Unfortunately, I clicked through without meaning to, and wound up installing to the default directory instead of the external where I wanted.
    8). Upgrade was completely successful. FG opened correctly.

    So - sorry about the length of this, but I'm not sure if my fixing permissions on the updater itself is what fixed the problem, and if that means I would have been able to update and download to the external as I wanted, or if those permission settings have nothing to do with it. Either way, I'm hoping someone can answer a couple of basic Mac questions regarding this incident, and that what I did here gives someone else with the same problem a bit of hope.
    Did you use the default installation directory or choose another location?
    Does your user have permissions to create directories in the external location you chose for the data directory?

  9. #79
    Quote Originally Posted by smelton View Post
    Did you use the default installation directory or choose another location?
    Does your user have permissions to create directories in the external location you chose for the data directory?
    My first try, the program would only install into the Applications directory, but I tried to change the data directory to an external drive, and it kept failing on permissions. My second try, (after changing the permissions for admin on the FGU updater), I intended to do the same thing, but accidentally clicked through. Wound up installing to the internal hard drive instead.

    I am admin, and a far as I know, I should have all read/write permissions. I still get popups asking if I want to allow things, but I'm capable of doing that, and changing security settings.

    I thought it was odd that permissions for my username (Netjera), were read and write, but permissions for (Admin) were read only.
    Art, Games, Life
    www.netjera.com (In progress, so be kind, please)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
FG Spreadshirt Swag

Log in

Log in