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?
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, 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.
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.
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.
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.
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:
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.