Trying this again since my last (only) post (attempt) was quickly marked as spam and subsequently deleted... going to copy pasta since I happend to leave the tab with the post open.
vCenter 6.5, everything is presented via NFS.
SQL Backups are working, but verification is always failing.
We have 2 separate servers for offloading verification.
The run as account is admin on both servers; it is sysadmin in both SQL instances.
All verifications fail with essentially the same error(s.)
2019-05-13T05:57:56.8981181-08:00 ERROR SMCore_36898 PID= TID= [Verification] Backup verification failed for 'sqlp\PRODUCTION\PHINMSG' database with below error. A database snapshot cannot be created because it failed to start. A database snapshot cannot be created because it failed to start. CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\scmnpt\mpdisk0326\Program Files\Microsoft SQL Server\MSSQL14.PRODUCTION\MSSQL\Data\PHINMS_Message.mdf_MSSQL_DBCC6'. The database snapshot for online checks could not be created. Either the reason is given in a previous error or one of the underlying volumes does not support sparse files or alternate streams. Attempting to get exclusive access to run checks offline.
This morning, a different SQL instance had left a total of 8 orphaned volumes on the NetApp, and those 8 vols were left attached to one of the verification VMs.
I've validated NTFS permissions.
I even explicitly add the run as account with no change.
The SQL logs report the same error.
We have another identical setup in a different datacenter, using same run as account, that is successful with SQL verification and offloading.
I've searched and searched for what all occurs for the verification process, but I have found no documentation that clearly details the steps taken for the verification process.
May not be the same as your issue, but i encountered similar error when the SQL Server serviceaccount on the verification server (domain\svc-sql-verify) was different than the SQL service account on source SQL server (domain\svc-sql-accounty).
If this is the same in your case, you can try giving the verification SQL Server serviceaccount full control to the files on the source SQL Server.