“You do not have permission to open this file.”  This error is always, always, always in reference to insufficient permissions on a shared folder or file, usually a forms or reports dictionary.  This behavior could happen when users are forcibly disconnected from a network resource, or unsynchronized AD Catalog Server permissions are accessed causing a conflict in access rights.  We usually see it when a new GP user has not been granted sufficient rights (Read/Write/Modify) in the shared file area (usually GPShare).  This issue may also present itself as an “Unknown Dictionary Error” if it appears prior to SQL login.
The GP launch chain of events is as follows:
  1. GP opens with Dynamics.exe calling business logic dictionaries listed in the Dynamics.set file.  Some of these paths may be on a different server.  No SQL connection is attempted, requested, or required at this point.
    1. If all dictionaries are accessible and open for read/write operations,  the application launch proceeds to validate the SQL user.  If dictionaries do not have proper permissions or are inaccessible, the login fails with the “You do not have permission to open this file” error.  Note that depending on domain file sharing policies, if a terminal server still shows the user running a copy of Dynamics.exe, a domain group policy may deny the user access to a second copy of the file, which would yield the same error since access would be specifically denied.
  2. Once Dynamics.exe loads all the logic specified by the SET file, the SQL login screen opens for the user.
  3. Data is provided by the SQL Server databases, and windows are loaded from the logic dictionaries mentioned in #1 above.
  4. To finish the operations scenario, GP transactions are client/server, with GP requesting as much data as necessary to satisfy the query which is then processed on either client or server depending on the transaction.  This is done through many ‘top 25’ queries until the desired data has been received to guard against large blocks of data transmitting at one time possibly overloading the network.  This constant request for data and the validations against it are the reason that server and client must reside on the same LAN.