Hi Everyone, First off I'd like to thank everyone whom wrote back to me privately with some suggestions on how to fix this issue. (Original question at bottom of message.) Though I'm glad people wrote to me privately I wish they would reply back to the mailing list as well as I often find answers to questions I have in mailing list archives.
I also wanted to write back to say that I finally have gotten the issue resolved, though after having spent way too much time on it. (Netapp support was seemingly unable to help me resolve this issue.)
Kudo's to Nick Bernstein for having a suggestion which was very close to the actual fix. Though I must admit that I didn't think his suggestion was close to the issue I was having and thus didn't look into much until the very end of my research. (A.K.A. a lot of wasted time on my part :( )
Here is Nicks response:
When you first access a volume over nfs, it does a create/convert
unicode on the volume. Snapshots are read-only, so they can't have the same conversion applied. This is normally the cause when you can access the normal volume, but not the snapshots for it. Once new snaps are taken you should be able to access the new ones.
The fix to the "Access Denied" error when trying to access a snapvault destination qtree with unix security via cifs is to set the options convert_ucode and create_ucode to on *before* you initiate the snapvault relationship with "snapvault start" otherwise the qtree is created without the unicode encoding and since the snapvault dest. is read only changing the ucode options after the qtree is created doesn't help and thus you have no access to any of your data (including new snapshots) via cifs, though nfs access is still fine.
Hope this helps someone save some time in the future.
What eventually tipped me off was this knowledgebase article, which is written for snapmirror but is similiar enough to the issue that I was having with snapvault that I was able to figure it out.
https://now.netapp.com/Knowledgebase/solutionarea.asp?id=kb23656
Romeo
Original Question:
On Thu, Oct 22, 2009 at 11:32 PM, Romeo Theriault romeotheriault@gmail.comwrote:
Hello, We have a VMware environment with nfs as the transport protocol. What I'm testing out is snapvaulting the vmware datastores to another filer and then creating cifs shares on the snapvaulted volumes (qtrees), so the windows client vm's can access their vmdk files to restore files. I should state that I'm a newbie to cifs on the netapps as we are a unix shop. But, I have the snapvault setup all working. Where I'm running into problems is accessing the directories in the shares when I map a drive in windows to the share.
I configured cifs to authenticate against:
(3) Windows Workgroup authentication using the filer's local user accounts
So I created a user 'vmrestore' though the useradmin tool and user vmrestore is part of a group cifsonly which has role none assigned to it. I then added an entry to /etc/passwd for the vmrestore user. At this point I can create a share to the vmware .snapshot directory on the snapvault destination and give the vmrestore user access to the share via:
filer> cifs access vmsnaps vmrestore rwx
I can now connect to the share fine but cannot access any of the shares folders as I get a "Access is denied" error. I've been reading the netapp docs and googling around for a while now but am having a difficult time understanding how I need to configure the local user account so I can access the folders/files on the unix security style volumes.
I've tried mapping the vmrestore user to the root user via the usermap.cfg file. Thinking that since the vm files are owned by root maybe the vmrestore user has to be mapped to a user with a uid of 0 to have access to them. I've also tried the --forcegroup option on the share.
Basically, I'm not having any luck and wanted to see if anyone has run into this (or just knows what I'm doing wrong).
Any help is very much appreciated.
Thanks,
-- Romeo Theriault System Administrator Information Technology Services