This report couldn't access the data source, for some users, sometimes

[Anonymous]

Hi!

We're using a setup with SSAS hosted on a azure server, and direct connect Power Bi reports. 

We use RLS in SSAS and a Gateway (keeps it updated).

Some users maybe 10-20 out of 120 sometimes gets this error message:

This report couldn't access the data source. Contact NAME, the report author to get it fixed. 

When this happens usually most visuals won't load, but a few usually does. 

There's no consistency, that I've noticed, when it happens or for how long. It seems to affect a few people more often than others but they have no connection, different roles and countries. 

This has been going on for at least 6 months. 

[morteza]

I have the same issue (getting the error message: "This report couldn't access the data source. Contact NAME, the report author to get it fixed".) while used Incremental Refresh for a Power BI report with the DirectQuery enabled for the last month of data. I haven't set up any RLS for this report and this error is shown to me who is the owner of the report. The report gets refreshed successfully using the on-Prem gateway to a SQL Server connection and when I re-publish it to a different workspace without the DirectQuery (Import Only) it works fine. Any ideas or solutions?

[v-janeyg-msft]

@Anonymous  Any updates?

[v-janeyg-msft]

Hi, @Anonymous 

First, I think you need to refresh your dataset in service to test whether the gateway works well when the problem occurs. Then you can check whether user rights and row level security match.

A combination of lower user rights on a workspace and row level security on the data could hamper your access.

Have you configured map user names for Analysis Services?

Each time a user interacts with a report connected to Analysis Services, the effective user name is passed to the gateway and then passed on to your on-premises Analysis Services server. The email address that you use to sign in to Power BI is passed to Analysis Services as the effective user.

The email address must match a defined user principal name (UPN) within the local Active Directory domain. The UPN is a property of an Active Directory account. The Windows account must be present in an Analysis Services role. If a match can't be found in Active Directory, the sign-in isn't successful. To learn more about Active Directory and user naming:

map-user-names-for-analysis-services-data-sources

You can try to delete the database role and re-creating it.

Did I answer your question ? Please mark my reply as solution. Thank you very much.
If not, please feel free to ask me.

Best Regards,
Community Support Team _ Janey

[Anonymous]

Hi!

Thank you for your answer, it helped but didn't solve it. 

I don't understand the part of user rights, I've given the users acces to the workspace as members and then RLS in visual studio for the data model. Nothing else. 

I've found two work arounds:

I gave one user non restricted rights in RLS and now it works, however I will need to find a way to limit his rights. 

The second I used the map user function you described but replaced one persons user with another and then it worked. 

So I guess that narrows it down to a RLS problem? 

I tried creating a new Role with a simple rule, but that didn't work for these users either. 

I also tested cmd: whoami /UPN, and created pbi reports with USERPRINCIPALNAME and USERNAME to check that all looked normal for the users and it did. 

Best Regards 

Rickard 

[v-janeyg-msft]

Hi, @Anonymous 

If all users have member permission, the problem must be in the data source. In your case, it should be the problem of RLS.

If UPN don't match, you should configure map use name feature for all users who need to view reports. Please read the document again.

And since I don’t know how you set up RLS, I think you need to check and modify it yourself.

Did I answer your question ? Please mark my reply as solution. Thank you very much.
If not, please feel free to ask me.

Best Regards,
Community Support Team _ Janey