We are a service provider supporting a school environment where Audacity is installed on terminal servers. The application consistently fails to access the audacity.cfg file, displaying an error message that appears to be common across various support forums.
We have identified the root cause: the issue arises when Group Policy settings are applied to restrict student access to the local drive (C:). Specifically, we use two GPO policies:
Hide drive C: to prevent visibility of the drive.
Prevent access to drive C: to block direct access.
These policies are essential to prevent students from creating unauthorized folders on the C: drive, which they could misuse for cheating or chatting.
While removing these restrictions allows Audacity to function correctly, this workaround is not acceptable in our environment due to security and policy compliance. Notably, most other applications installed on the terminal server operate without issue under these GPO settings.
We believe the issue stems from the way Audacity accesses its configuration file (audacity.cfg). Unlike other applications that use Windows-compliant methods such as accessing %APPDATA% via the Windows Known Folder API (SHGetKnownFolderPath) or similar abstracted access mechanisms, Audacity appears to rely on direct file system access to the C: drive. This method fails when Group Policy restrictions are in place to hide or block access to drive C:, even though %APPDATA% itself remains accessible.
Suggested Improvement: Please consider revising the file access implementation to use standard Windows APIs for accessing user profile paths. This would ensure compatibility with environments where drive C: is restricted, without compromising functionality.
I’ve tested the issue further, and unfortunately, the same error persists. Audacity is unable to access the configuration file, even when the user downloads and runs the portable version in their own context.
It seems that Audacity still attempts to interact with the config file that is stored in c:\users\%username%\roaming\audacity\audacity.cfg , and fails when that access is restricted.
Audacity may be getting that information from the APPDATA environment variable (or some other environment variable). You may be able to experiment with changing it in a batch file before running Audacity. To see the currently configured environment, open a DOS command window and enter SET without any parameters.
As a follow-up to the previous post: I’ve realized that a truly portable application should operate strictly within its own directory—it shouldn’t reference external paths. Unfortunately, Audacity doesn’t follow this behavior, which I’d consider a second bug.
Regarding %APPDATA%, it’s a widely used system location for storing user data across many applications. I’d advise against modifying it, even temporarily.