none
Browser permission the folder, but some reports give error RRS feed

  • Question

  • Some of our users are experiencing the following permissions error on certain reports in SSRS:  "The permissions granted to user 'bla\bla' are insufficient for performing this operation (rsAccessDenied)"

    Facts about the configuration that explain why this should not be happening are:

    • We have a 50+ reports in the this particular folder in SSRS 2016.
    • Browser permission is set at the folder level for the Active Directory group “ourdomain\Domain Users” which has all users in our company.
    • I have confirmed that the users in question are in this "Domain Users" group.
    • I have confirmed that these same users can open other reports in this folder.
    • I have confirmed that the reports in question do not have any other permissions set up and are inheriting their permissions from the parent folder (i.e., Browser permission).
    • The data sources on the reports use a generic application login and nothing about the report itself is connecting as the current user (thus the error must be coming from Report Manager, not the running or rendering of the report)

    Some things I’ve attempted:

    • Added the user directly to the folder with Browser permission – same error
    • Broke the permission inheritance on the report – same error
    • Broke the inheritance and added the user with Browser directly to the report – same error
    • Redeployed the report from Visual Studio – same error
    • Completely deleted the folder and all reports, recreated the folder, re-added the group level Browser permission to the folder, redeployed all the reports in the folder – same error

    We’ve see 4 or 5 reports so far out of the many in this folder where these users have this error and I can find anything about the reports or the users that would cause this behavior.

    Help!


    Organon Professional Services

    Tuesday, August 20, 2019 10:47 PM

Answers

  • Solved: And it was simple and I feel stupid.

    Worked with Microsoft Support and we got this figured out.  Turned out to be a simple problem where the reports involved referenced shared datasets.  Those shared datasets were in a different folder and the permissions on that folder didn't include the same AD group as the folder with the reports.  Added the missing Browser permission to the Datasets folder and everything worked.

    On the one hand, I feel like an idiot for not realizing this immediately given it's obvious that those datasets were involved since they're right there in their own node in VS when I deploy.  Also, I feel like an idiot for not doing what the Microsoft tech did...look at the bloody logs!  I've been so busy with everything else involved in my recent migration that I didn't think to comb through the SSRS logs on the server.  I looked through the Event Viewer logs when I was first researching it, but didn't dig into the SSRS folder structure on the server and find its logs.  The answer was there!

    On the other hand, any other time that SSRS has an error from SQL running a query, it tells you which dataset was the problem.  If the error message had stated that the user did not have access to a dataset, I would have immediately know what it was.  But the generic error in the browser mislead me.  The server knew full well that it was a permissions error on a dataset, because it wrote that to the log.  It sure would have been nice if it had written that on the freaking screen!


    Organon Professional Services

    • Marked as answer by TimGraffham Thursday, August 22, 2019 3:46 PM
    Thursday, August 22, 2019 3:46 PM

All replies

  • Hi Tim,

    I've also one time encountered similar issue like yours. It seems you have done a good check to your server.

    One thing I've tried is to save and redeploy the report to server with a new file name, and deleted the old one. This works for me last time.

    BTW, may I ask, how did you get this error, have you done any kind of migration ?

    Lukas


    MSDN Community Support Please remember to click Mark as Answer; the responses that resolved your issue, and to click Unmark as Answer if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Wednesday, August 21, 2019 2:52 AM
  • Excellent plan.  Sadly, it didn't work.  We did do a recent migration.  The reports in that folder were all part of our SQL 2008 installation and had been running for years with no issues.  We recently upgraded (FINALLY!) to SQL 2016.  I brought all the old reports into shiny new solutions in Visual Studio 2017 (with real source control and everything; how modern!  :)

    I got everything converted and built in VS2017 and everything works great.  I deployed everything to the new 2016 servers and tested everything.  All was well.  Then we went live.  Again, as I've described, everything is working perfectly in this folder except a few reports that are getting this error for a few users...and there's no pattern!  One report works fine for everyone else, but errors like this for 1 user.  Other users can run that report just fine, but they have a different one that gets this permissions error.

    Its very frustrating.  I'm working with Microsoft Support to try and figure this out.


    Organon Professional Services

    Wednesday, August 21, 2019 5:58 PM
  • Hi Tim,

    From SSRS2008 to SSRS2016/17, both SSRS and BIDS- SSDT have damatically changed.

    This kind of migration will cause unfortunately inevitable errors in report definition seen the so many changes and updates in the development environment.

    Only another try, if the report is not very complicated,you could remake it in report builder 3/ SSDT2017. New a file in this new development tools may possibly resolve this issue.

    Regards,

    Lukas


    MSDN Community Support Please remember to click Mark as Answer; the responses that resolved your issue, and to click Unmark as Answer if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, August 22, 2019 1:39 AM
  • Solved: And it was simple and I feel stupid.

    Worked with Microsoft Support and we got this figured out.  Turned out to be a simple problem where the reports involved referenced shared datasets.  Those shared datasets were in a different folder and the permissions on that folder didn't include the same AD group as the folder with the reports.  Added the missing Browser permission to the Datasets folder and everything worked.

    On the one hand, I feel like an idiot for not realizing this immediately given it's obvious that those datasets were involved since they're right there in their own node in VS when I deploy.  Also, I feel like an idiot for not doing what the Microsoft tech did...look at the bloody logs!  I've been so busy with everything else involved in my recent migration that I didn't think to comb through the SSRS logs on the server.  I looked through the Event Viewer logs when I was first researching it, but didn't dig into the SSRS folder structure on the server and find its logs.  The answer was there!

    On the other hand, any other time that SSRS has an error from SQL running a query, it tells you which dataset was the problem.  If the error message had stated that the user did not have access to a dataset, I would have immediately know what it was.  But the generic error in the browser mislead me.  The server knew full well that it was a permissions error on a dataset, because it wrote that to the log.  It sure would have been nice if it had written that on the freaking screen!


    Organon Professional Services

    • Marked as answer by TimGraffham Thursday, August 22, 2019 3:46 PM
    Thursday, August 22, 2019 3:46 PM
  • Everyone could overlook or miss some simple thing, so it's not stupid. :)   Sorry for my misleading, but anyway, glad it has been solved.

    Cheers.


    MSDN Community Support Please remember to click Mark as Answer; the responses that resolved your issue, and to click Unmark as Answer if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Friday, August 23, 2019 1:52 AM