ZygoCorp
Level 6

getting permission errors accessing files/directories on windows 7

so I finally got my 64-bit release built and working - sort of. Of course we are going to be releasing on Windows 7, 64-bit. My components all seem to install properly, shortcuts work, registry entries as expected. Then when I launch my desktop shortcut, I get 'Access to path xxxxxxxxx is denied.' [xxxxxx is a path created by the installer where ourt exe is located.] When our software starts, it looks for a license file. If it doesn't find it, it creates it - well, it tried and was DEE-NIDE by windows 7. Windows XP this works great. (I skipped over Vista completely. ) If I launch the shortcut by selecting 'Run As Administrator' it works just fine......but of course not only will our users NOT be running as administrator, they won't even be logged in as administrator (like I was when I encoutnered this error).

Any suggestions on how to fix this, or what special steps I need to take, or a pointer to a useful document/article would be greatly appreciated.....
Labels (1)
0 Kudos
12 Replies
ericpaul
Level 6

Try setting the permissions on the folder where you want to create the shortcut.
If that helps you might want to have a look at the How to set folder permissions with cacls? thread to set permissions.
Permissions can also be set from within Files and Folders in InstallShield, however we experienced that certain existing permissions are then removed,
so we resorted to using icacls on Windows 2008 R2 (cacls is for XP).
0 Kudos
heathlmorris
Level 4

You can set permissions in the executable inside your project by right clicking on it inside the files and folders view.

[LIST=1]
  • Select Permissions
  • Press "Insert to use a new user group"
  • Enter "Everyone" (This is a group defined by windows to specify everyone)
  • Leave Domain Alone
  • Select Read & Execute
  • Select OK


    I would not give permissions to the entire folder unless youre application needs to write data out to those directories. Otherwise I would only give permissions to the neeeded files. This is good practice even for XP because if you have limited users on xp they can now run your application as well.

    Best Regards,

    Heath Morris
    Release Manager ProModel Corporation
  • 0 Kudos
    heathlmorris
    Level 4

    Here is a screenshot
    0 Kudos
    MichaelU
    Level 12 Flexeran
    Level 12 Flexeran

    The correct fix depends on what you can change, and what exactly the scenario is. If this is a predetermined file that you can install, then it might be okay to change permissions on that single file similar to what some of the comments above suggest. But anything of this nature is fighting the security model that Windows gives you.

    If instead you can modify the program itself and don't need to write to this license file, make sure it's being opened only for read access, as a limited user shouldn't have write access to ProgramFilesFolder. If you do need to write to the file, it should probably be relocated to a program-specific folder under the user's LocalAppDataFolder.

    If the data really needs to be shared across multiple users, it might be better to use the public documents folder or the CommonAppDataFolder (ProgramData folder). However for this there's not a significant security savings, so you'd have to weigh the cost of the change over the cost of extra steps in your setup in the first (change permissions) suggestion.
    0 Kudos
    ZygoCorp
    Level 6

    Thanks all for the ideas. Will review and try. Wish the Windows 7 webinar was LAST MONTH!! waiting til the 13th ro move forward on several items is killing us......Sorry it took me so long to review. I thought I would get an email when someone responded to my question but I didn't....
    0 Kudos
    ZygoCorp
    Level 6

    Right clicking on the file in the files and folders view - or any view - does not offer a Permissions option- only: Add, copy, delete, refresh, opencontaining folder, and properties. So I still don't understand how to make my exe run for all users. (the issue isn't just running via the shortcut, its also running it from Start > Programs. Please remeber this is an InstallScript project.

    As for the access denied, the file is not installed. It is checked by the exe and created if it does not exist. Sounds like the developers need to get the file moved to the appropriate Windows 7 location.
    0 Kudos
    Lurean
    Level 8

    since the file you are trying to create is not part of the installations setting the permissions on the executable won't have any impact on the ability to write the file, but if you ever do need to know how to modify the permissions for a file you jsut right click the file in file and folders view and select properties. In the lowr right corner there is a Permissions button that will open the permissions view for the file.


    The only way to correct the issue you are having is to either install a blank license file and have the permissions set to allow anyone to modify it, or to have the drop location of the license file changed to a publicly accessible location that all users would have read/ write permissions to. Either of these solutions would likely require a change to the code by the developers of the application.
    0 Kudos
    ZygoCorp
    Level 6

    Post is about 2 different issues.

    (1) being able to launch the installed exe without running 'as administrator'
    (2) the exe not beinfg able to create the license file

    For #2 - on windows XP we found that we had to set permissions on some directories that our exe used during operation. Thought maybe this was somehow a similiar incident. It is but under the much bigger UAC umbrella context so the real issue isn't permission into that directpory, its that the directory is inappropriate given UAC and should be changed by the developers.

    I still don't understand what to do with the installer to have our exe run for all users.
    0 Kudos
    MichaelU
    Level 12 Flexeran
    Level 12 Flexeran

    You can find a lot of pointers for making an executable run with administrator privileges with search terms such as: UAC Manifest. If your developers are using Visual Studio 2008, support for modifying this manifest is built in as an option. If they're using something else (such as earlier versions of Visual Studio), it should still support the manifest but likely not quite as directly.

    There are ways to make a shortcut specify the run-as-administrator flag, but they are not the correct approach. Search terms for this incorrect approach include: IShellLink RunAs.
    0 Kudos
    ZygoCorp
    Level 6

    But isn't the point of all the UAC stuff etc is to NOT run as administrator? That's the impression I get when reading the Windows 7 Logo program information.
    0 Kudos
    MichaelU
    Level 12 Flexeran
    Level 12 Flexeran

    It absolutely is, at least for most programs which do not require administrator access for their functionality. This is generally not something that you can patch over in the installer, although arguably changing write permissions on global directories can come close. Instead it normally has to be addressed in the program itself (for example as we talked about above with the location of your runtime-written license files), and then the installer can support the program by setting up the initial state.

    Some programs do things which genuinely require administrative privileges. Such programs should have the proper settings in their manifest (like Process Monitor). Some only need these privileges sometimes, and those programs can choose how to set their manifest, and whether to relaunch themselves with elevated privileges (like Process Explorer).
    0 Kudos
    phill_mn
    Level 7

    If I follow this thread, the issue is that the application is trying to create a file in the application's folder, typically under program files. A typical user does not have the rights to do this. Yes folder permissions could be changed as suggested above or the application could be marked to "requireAdminiustrator", but neither of those suggestions are really the advised solution to this problem. The design of the application should be changed to create the file in a location that the user is allowed to write too. When we started supporting Vista we had to change our applications to call SHGetSpecialFolderPath and CSIDL_COMMON_APPDATA\[ApplicationName] or one of the other paths depending on what you are doing. Applications should have taken this approach on Win XP also, but for Vista and later this is a common change. Phill
    0 Kudos