User unable to edit a subscription after migration of SSRS from 2008 R2 to 2017 I performed a migration of our SSRS 2008 R2 instance to a brand new SSRS 2017 instance.  This was accomplished via Microsoft's documented instructions "Migrate a Reporting Service Installation (Native Mode)":  Backup/Restore of the DBs, setup of the RSExecRole in the system DBs with permissions, import the encryption keys for the old server.  Everything is working well and we're slowly turning on reports in the new environment and turning off in the old after testing.

Everything seems to be working except for this one thing:  We give our DOMAIN\Domain Users group access via Site settings.  It's a System User.  And, for a particular folder of reports, we have a user who is explicitly added to that folder by domain account name with permissions more than sufficient to edit subscriptions.  And, this still works fine.  However, when a user who did not have this explicit access/permissions on the old server was added to the folder on the new server in the same fashion, he is not able to edit an existing subscription.  The error is "The permissions granted to user 'DOMAIN\USER' are insufficient for performing this operation"  This is despite the user not only being a member of all the same roles as the existing user but being added to the System Administrators role in Site settings. (!)

The error occurs when the user clicks the "Edit" link for the subscription.  The subscription page begins to open but the error dialog appears and the page is greyed out.  The user can create a subscription (or at least get the page to open).  It doesn't matter whether the subscription is data driven or standard. It doesn't matter if the subscription existed before the migration or was created after.

Given that the user now has all the permissions possible in SSRS, I'm not sure where to look next.  It's baffling to me that the function works in general, it just doesn't work for someone who was given permissions after the migration.

Both the old and new server are running under the same service account.
After a week of mucking around with permissions and getting ready to place a support call with Microsoft, Bart Edgerton's final suggestion to me in the Slack SQL Server Community workspace gave the solution:  I needed to give the user permissions to the folder containing the data source used by the report.  

It's a bit odd to me as editing a subscription doesn't allow the user to edit the data source.  But, after a week puzzling over this and tweaking every permission under the sun, I'm at peace with it.

And, finally, this wasn't a migration issue.  At least, not related to my current 2008 to 2017 migration.  The same problem exists on the 2008 SSRS instance.  But, that instance was itself a migration from 2000 or 2005, I don't recall which.