NetApp CIFS is NOT windows file server?

[shenyuguo]

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1035094

Just come across this VMWare issue, and they claimed that CIFS is not windows file server, can anybody share, what's the different, any workaround?

[andrc]

Strange as it says "ThinApp support requires that the packages are located on a Windows fileserver, or a fileserver that can support authentication & file permissions based on Active Directory computer accounts"

It could be because CIFS shares can use workgroup authentication and as stated AD authentication is required, maybe it's been worded incorrectly?

[shenyuguo]

Thanks for your quick response!

"Active Directory computer accounts"

This is the keyword, maybe default CIFS can authenticate based on user accounts, not computer accounts?

[f_duranti]

We have the ThinApp Repository on a CIFS share on NetApp storage and it works correctly.

I don't know if your problem is that you're not able to add computer account on the share permission with the netapp interface. We manage netapp shares from "computer manager" of windows 2003 servers. Just open computer manager, choose to manage another computer and put the storage name. Then you can go on "system tools, shared folders, shares" and from there you can create/manage shares on the storage. To add a computer account you should go to the share permission, click on add and then choose from object types "Computers" then you can add the computers to the share persmission.

[RAFAEL_GUEDES]

Hi Francesco,

We are also facing the same situation. As you stated, I set the permissions so computers could authenticate against NetApp shares.

I have the the scenario as bellow:

* I have a multistore context acting only as a CIFS file server;

* This context has two partitions:

/vol/context_root (NTFS sec style) - root volume

/vol/context_shares (NTFS sec style) - shares volume

* Volume context_shares has two qtrees:

/vol/context_shares/shares

/vol/context_shares/thinapp

* The context (vfiler) is integrated in domain and I choose NTFS only when I run 'cifs setup'.

I've created a share on /vol/context_shares/thinapp through MMC (computer management):

* I set the share permissions 'read' to: Domain Computers, Domain Controllers and Domain Users

* I set the share permissions 'full control' to: Domain Admins

Because if I would change the permissions at the share level I would lost inherited permissions, I've created a folder inside the share and I put the permissions bellow in this foldes:

* I set the security 'read', 'read & execute' and 'list folder contents' to: Domain Computers, Domain Controllers and Domain Users

* I set the security 'full control' to: Domain Admins

Even, I receive the same log messages in the View Administrator Console. Could you help us with this sending me your configuration?

Thanks a lot!

[mjschneider]

Rafael, have you tried setting the 'share' permissions to everyone-Full?  Then just manage permissions via NTFS.  My train of thought is that maybe share permission authentication is handled differently than NTFS; from the file server's perspective.

[RAFAEL_GUEDES]

Hi,

I've tried this, but doesn't work. I found a related issue with Windows 7 and W2K8-R2 as you can see in this link https://kb.netapp.com/support/index?page=content&id=2013374.

I'm trying this workaround at this moment and I'll post my results. Thanks!

[mjschneider]

That makes sense.

This may not apply to this scenario; but we did have issues accessing netapp cifs shares on windows 7 when first going through a win2k3 DFS server.  I think it had to do with NTLM versions.  Upgrading to 2008 dfs servers fixed the issue.

[RAFAEL_GUEDES]

Now the error has changed.

I got the error:

HRESULT hr = 0x80070005 Access Denied

I really don't know for who the filer was denying access to. There is a way so I can monitor some log to see which user has been denied?

[mjschneider]

You might catch it in the auditing logs.  You have to turn it on in ontap and on the share.  Check the docs, it's been a while since i've messed with auditing.

[columbus_admin]

Rafael,

     You can try setting options cifs_trace_login on, but if this filer is busy with CIFS transactions you will want to turn it on, quickly attempt to connect, then turn it back off.  This log can scroll by very quickly.

You will be looking for the [auth.trace.xxxxx] entries, and the check from the IP of the machine you expected to connect.  When I have it set, I see:

"[auth.trace.authenticateUser.loginAccepted:info]: AUTH: Login by username from ip_address accepted."  Or denied based depending on the situation.

- Scott

[RAFAEL_GUEDES]

Hi Scott we're in the deployment time yet, so we can easily check these entries. Now the problem is solved, I've recreated the vfiler, joined in the domain, create a share and set the right permissions. First I've tried the permissions that Francesco said me and the access was OK, after I put a filter and setup the permissions in a more closed way.

[f_duranti]

My configuration is probably simpler, I've a relaxed security on the share (Everyone full control) then I've setup access at share level. I've the single computer account of my Connection server having "Full control" and then everyone "Read" on the share permissions.

It works correctly. You can also enable those 2 options on the vfiler to check what is happening and if user/computers are authenticating correctly:

cifs.trace_dc_connection	on
cifs.trace_login	on

Francesco

[RAFAEL_GUEDES]

Hi Francesco,

Thanks for help. I've recreated the vfiler, joined the domain again, created the share and set the permissions as you stated. The access was OK. After doing that I changed some permissions based on the access log that I capture from vfiler.

Thanks again!