PDFs created by Mendix app cannot be opened by non-admin users – Access denied at OS level

0
Hi everyone,We're running a Mendix 9 on-prem app that generates PDFs and stores them on a network drive (mapped as L:\). This has been working fine for a long time, but since early February 2026, users without admin rights get the following error when trying to open the PDFs:"Error [Operating system]: Access denied."Users with admin rights can still open the files without any issues.Around the same time, two things happened:1. Our Azure AD Client Secret was renewed and updated in the OIDC SSO module within the app.2. Our former main Mendix developer left the company and his AD account was deactivated.What I've checked so far:- SSO is working correctly – all users can log in, so the secret appears to be configured properly.- There is no hardcoded file path in Studio Pro – file storage is configured server-side, not in the app code.- No connection between the Azure Secret and the PDF export exists in the code.- The app also uses DocmosisCloud (with an APIAccessKey) for PDF generation and an EmailTemplate module with Azure OAuth, both configured in runtime settings.My current theory is that this is an NTFS permissions issue on the file server – possibly caused by the Mendix Windows service running under the former developer's (now deactivated) AD account, which would change the security context under which files are written.Has anyone experienced something similar? Specifically:- Can the Mendix service account affect NTFS permissions of generated files?- Is there any known connection between the OIDC secret and file storage behavior in Mendix 9?- Could the DocmosisCloud module or any other component be involved?Any insights would be greatly appreciated. Thanks!
asked
1 answers
0

Your theory is almost certainly correct. The Mendix Windows service is running under that deactivated AD account. When the service writes files to the network drive, it does so under whatever identity the Windows service is configured to run as. If that account got deactivated, the behavior can get weird in ways that dont always break everything at once, depending on cached credentials and token lifetimes.


Check the Windows service on the server, look at the "Log On" tab, and see what account its running under. If its the former developers account, switch it to a proper service account with the right NTFS permissions on that L:\ drive. This has nothing to do with OIDC or the Azure client secret, and nothing to do with Docmosis either. Those are application-level concerns, the file writing to a network share is purely an OS-level thing determined by the service identity. The timing with the secret renewal is just a coincidence since it happened around the same time the developer left.

answered