We are experiencing a problem trying to create an iscsi LUN for a SQL cluster using snapdrive. In the windows event log we get the message:
error code: current user (SQL03\snapdrive) is not allowed to perform this operation (SD.Storage.Write) on this resource (fas-3140-1-a:/vol/L_CLUST01_Q)
i am fairly sure i have followed the guides so i am a bit stuck now.
The filer in question is running dataontap 7.3.3 and is part of a cluster.The filer is joined to our main internal domain while the sql cluster is on the dmz domain - there is no trust between the 2 of them.
The windows servers are running 2008 r2 and have mpio and failover clustering enabled. We have not yet installed the netapp dsm.
i have created a local account (snapdrive) and added it to the local admins group on the cluster nodes
i have created the same name account (and same password) on the filer and added it to the administrators group (as per the snapdrive admin guides instructions for passthru authentication)
i have installed snapdrive with rpc access to the filer (we have temporarily opened up the windows firewall and also the dmz firewall to allow all access between nodes and filer)
i established the iscsi sessions on both
when creating the LUN i first tried logging on with my domain account and got the same error above (but with the domain account named in the error). Logging as the snapdrive account did not resolve the problem.
Have spoken to a colleague elsewhere who has suggested using multistore instead (this is an option but i would rather get the above working due to time constraints).
I am fairly new to netapp so may have missed something obvious otherwise suggestions welcome on what to try next.
DMZ servers are probably not part of the internal domain. Maybe it is an idea to use HTTPS authentication for the transport protocol. use the snapdrive account you created on the filer for authentication. Make sure the firewall people allow access to the filer
The problem is that SQL03\snapdrive is NOT part of the administrator group on the filer. SQL3 is the computername, not the filer name
It really should work. You can also run the service as the local system account if you change the transport protocol. I tried it several times. Check the /etc/log/ems file on the filer if ZAPI authenctication is attempted.
What I do is,
- Create snapdrive account on filer with administrator rights.
- Change snapdrive service account back to "local system account"
- Restart services
- Change default transport protocol to HTTPS or HTTP and fill in snapdrive account, try to browse
- If authentication failed, you should see a authentication failure on filer console and in /etc/log/ems file
user account on filer is in local administrators group
same name user account is local user on both windows cluster nodes (with same password)
user is local administator on both windows nodes
changed services to local system
made sure transport protocol is http
browsed to netap filer using accoutn above on both nodes - no problems accessing filer
[made sure windows firewall is down - also "proper" firewall allows access]
on one node i can tell from captures that the node is sucessfully talking to the filer over http - however still get the same problem - namely that when you Create LUN and then add the storage system name volumes are not dispalyed and then adding the volume name manually gives the error PSQL03\snapdrive is not allowed to perform this operation (SD.Storage.Write) on this resource (ip address:/vol/vol_name) - the username mentioned above chanegs if a use the dmz domain account.
On the other node i get an error showing the server as disconnected within the snapdrive snap-in. In the event log the error is:
Failed to get system information.
Error code: The remote server has been paused or is the process of being started
One thing I still don't understand. You are talking about PSQL03\snapdrive useraccount. This looks like a Windows account. Make sure you use a NetApp Local account in your transport protocol. This account you give local administrator rights on the filer. You don't need the same account on the local Windows server. If you use RPC as the transport protocol it is necessary to use domain windows accounts.
make sure the snapdrive services run as local system (both snapdrive and snapdrive management).Browse with snapdrive to the filer and verify that you have the correct permissions. Create an iscsi session.
That should work. If this doesn't work, Try to use the filer's root account as the transport protocol user. This only to test permission problems on the filer itself.
On both windows cluster nodes i have set the snapdrive and snapdrive management services to local system (there is also a data Ontap VSS Hardware provider service taht runs under the local account created on each server called snapdrive - this service is et to manual and i have not chanegd it)
the netapp has a local account called nsapdrive that is in the local administrators group on the filer in question.
The transport protocol is set to http (for testing at present) on both windows cluster nodes. I have added the snapdrive account here with same password as on the filer.
Following you suggestion i changed the account to root on both servers and got the following message when trying to create a disk (i was logged on as my domain user when trying to so this):
management ip address of filer
Current user (domain\mydomainaccount) is not allowed to perform this operation (SD.Storage.Write) on this resource (management ip address of filer):/vol/wL_PCLUST01_Q
i have logged the call with netapp and will start the process of following up with them.
Posting my findings even though this question was asked months ago. I had a customer ask me about the very same thing just a few weeks ago. Figure someone else might benefit from it.
Stop the cluster service on either node of the MSCS cluster and the local user account pass-thru authentication will work. Assuming the Filer local account used is the same as the local account used on the W2K8 server and the passwords are the same as well. Both need local Administrator rights respectively.
The issue seems to be the Windows 2008 Cluster service and the fact that it now runs as local system. Microsoft does not seem to support changing this.