Just thought I'd pop this up and see if anyone else is getting this same issue as I'm currently out of ideas.....
We have a special vb script that runs on all our workstations (Windows XP and Vista) which's logs some vital information to a file on the filer once the worksation starts up and before the users login. I have now been asked to make sure that our new image (Windows 7) also reports this information.
Currently to perform this task, I have a GPO which runs the vb script on the workstation. It is called within the GPO -Startup/Scripts/Windows Settings/Computer Configuration. No problems so far.
The script outputs the values to the log file on the san, the rights to this file are set as READ,WRITE and EXECUTE for the DOMAIN COMPUTERS group. This is where the trouble starts.....
All Windows XP and Vista machines appear fine, Windows 7 workstations appear not to have access rights even though I've checked the workstations and they are in the Domain Computers group.
The scripts is working fine via GPO on the Windows 7 boxes as if I change the log file path to the local C: drive, but fails on the SAN
Any ideas, have a missed something?
This KB article may address your issue. Windows Server 2008 R2 or Windows 7 clients connecting to a filer share fail
I also thought this article might be of relevance either now or in the near future since you're running Windows 7.
Luckily, I already spotted the snapshot issues with SMB and put SMB2 into place a while ago.
The GPO edit on the NTLM settings hasn't made any difference. I've just ran the script on a scheduled Tasks startup using a userid/password and that worked.
If I can't find a fix then I guess I'll have to do it that way.
hi, this sounds quite interesting.. just wondering are you able to access the SAN share from a windows 7 host, once you have logged on ok ?
Have you tried giving the computer account FULL control of the file on the SAN at all.
Also are any error messages logged in the event logs for your windows 7 host.
From the previous posts, it does look like an issue with Windows7, its just narrowing it down!
once I've logged onto the Windows 7 workstation is is fine (as it's using the user accounts security details rather than the Domain Computer account).
I've tried full control to the domain computers group without success and now I'm going to try and use the EVERYONE group, not what I want be may prove that it's possible.
I've got a gut feeling it's going to be something MS has changed in the local security policies by default, most of this kind of hassle I get is normally one or two MS oftions that changed such as NTLM, etc.
P.S can't see anything in the event log or on the filer system messages.
Just to keep you updated...
Well, after try the everyone group I 'm still getting the same issue, the Domain Computers workstations group permissions don't seem to be applying on the Netapp filer.
I decided to set the same permissions on a W2K3 server (Domain Computers Full Rights as my test on the SAN) and that worked. Hmmm, why are XP machines okay and not Windows 7?
looks like a slightly different issue then the one I have. All my security rights are added to the CIFS shared without issue but workstation (that's haven't logged in) don't appear to have the file rights even though I've used the Domain Computers group object.
Could it be something different with SMB 2.5 and Netapp Filer using SMB2.0?
We solved it, kind of!
Our solution was to use the pure IP address or DNS host record of one of the VIF's on the filer in our scripts rather than an DNS Alias record with pointed to our filers many vifs.
DNS alias record "data.domain.uk" would resolved to filerA-vif1.domain.uk and filerA-vif2.domain.uk host records.
We were under the impression that if vif1 went down, because all scripts point to data.domain.uk then this would still resolve but to the vif2 interface.
It appeared to work fine under previous versions of Windows but Win 7 didn't like it at all, as soon as the host address filerA-vif1.domain.uk was added to the script and the alias removed all was well.
Hope this helps,
I'm having this exact behavior with Win7 SP1 and Win2k8 R2 and a physical filer running ONTAP 8.1P1.
There are no vfilers or DNS aliases or anything strange like that to consider. The error messages I am seeing are identical to those posted in this thread earlier. Everything works just fine with WinXP and Win2k3. I have tried every possible combination of SMB 2 turned on and off, along with every single level of cifs.LMCompatabilityLevel with no change. Always works with XP and 2k3. Always fails with 7 and 2k8R2.
Has anybody found an actual resolution to this problem?
In case anyone is interested, NetApp Quality Assurance has just identified this issue as a "known bug" and has created a BURT for the issue. Although the BURT is not publicly viewable at this time, you can subscribe to it at the following location.
By default, Windows 2008/Windows 7 require CIFS SMB signing.
Do you have options cifs.signing.enable on? If not, this is what is causing the permissions issue.
This won't affect any clients who don't use cifs signing. Or, you can turn off the SMB signing requirement on the hosts through the registry.