Forum Discussion
PBIRS Sep 2026 Bug? Publisher Role Users Cannot View Reports
Hi everyone,
I recently upgraded our Power BI Report Server from the May 2026 release to the September 2026 release, and I encountered a critical change regarding user roles and permissions.
The Issue:
Prior to this update, users who only had the "Publisher" role on a dashboard or folder could successfully view the reports. However, immediately after upgrading to the Sep 2026 version, these users can no longer view their reports and are getting the following error message when trying to access them:
"User permissions error: You do not have permission for this operation. Contact your administrator to obtain the necessary permissions."
The Workaround:
We found that explicitly adding the "Browser" role alongside the "Publisher" role resolves the issue. Since doing this manually for hundreds of dashboards and users was not feasible, I wrote a custom PowerShell script using the native PBIRS REST API to recursively scan the server and automatically grant the "Browser" role to any user who only had the "Publisher" role.
My Questions for the Community:
- Has anyone else experienced this exact issue after upgrading to the September 2026 release?
- Is this an intentional security architecture change by Microsoft in this release, or is it a bug?
Thanks in advance for your insights.
3 Replies
- DaniyalKhaleel1
Resolver II
Interestingly, Microsoft had a similar permissions issue in January 2025, where Publisher/Content Manager users could receive permission errors accessing the /reports endpoint after an upgrade; Microsoft subsequently fixed it.
Your workaround of adding Browser + Publisher is reasonable, but I would not automatically modify hundreds of permissions permanently until Microsoft confirms the behavior.
I'd recommend opening a Microsoft support ticket and provide:
May 2026 build: 15.0.1121.x
September 2026 build: 15.0.1122.94/.95
Publisher-only user → permission error
Publisher + Browser → works
Minimal folder/report reproduction
Your REST API/PowerShell permission comparison
That should give Microsoft enough information to determine whether it's a regression in the September build.
Thank you for the detailed response and the great advice. Unfortunately, I don't have the required Microsoft support plan to open a direct ticket right now. However, I hope the product team notices this thread or others can report it using your excellent template. For now, the script acts as a temporary lifesaver for our organization!
jubinsoniMemorable Member
Hi amollaei,
One thing worth knowing whichever way Microsoft answers: by its definition, the built-in Publisher role is a "can add/manage content" role and does not include the view tasks that Browser has. So the September behaviour is at least consistent with the role definitions, and the earlier behaviour may have been the lenient one. That makes it worth fixing at the role level instead of per item.
Instead of granting Browser on hundreds of items, you can change what the role itself allows, in one place, with SSMS connected to the report server:
SSMS > Connect > Reporting Services > http://<server>/ReportServer -> Security > Roles Option A: Publisher > Properties > also tick: "View reports", "View folders", "View resources", "View models" Option B (cleaner): New role "Publisher + Viewer" with the Publisher tasks + the View tasks above, and assign that role going forwardOption A is one change and fixes every existing assignment immediately, but it alters a built-in role, so document it and re-check it after future upgrades. Option B keeps the built-in roles untouched but needs your script to swap assignments once.
Before rolling out either, test on one folder with one user, and export the current role assignments first (your REST script can dump Policies per item to CSV) so you can roll back.
So my overall approach would be:
Export current item policies (backup) -> Test role change on one folder/user -> Option A: add View tasks to Publisher (one change) or Option B: custom role, reassign once via script -> Raise with Microsoft to confirm intended behaviourAI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
