File Server Cluster - shares "access denied" on a node.

[m***@gmail.com]

Hi there.........

Need some directions please......

Our co. has an 2"2 Node" Active Active File Server cluster setup with
SAN and 2 Cluster Groups and in each group we have a physical disk
attached and some file shares created.

We recently added another SAN storage to the cluster and hence created
another cluster group with some shares and network name, ip address
etc.

However the strange thing is after creating the new cluster group, I
found that when I move the groups to a particular node it seems that
users cannot write to the file shares after the node transfer, but if
I transfer it back to the other node users can write to the cluster
shares fine.

So I have Physical Node A and B, when all the resources are on node B
the cluster shares are fine users can write to them, but once I
transfer to node A users get an error message "access denied" when
they try and write to the shares.

Anyone have ideas, is it something to do with the "Quorum", I haven't
tried powering down both nodes and restart them one by one since we
don't have outage time at this stage.

But has anyone encountered such as issue before.....

[Marcin]

How did you configure permissions on the shares in question? Are you using
domain local or global group (rather than local groups from the Node B) to
control access to them?

hth
Marcin

[m***@gmail.com]

The cluster shares were working fine before adding the new resource
groups, I'm wondering whether something was messed up with the cluster
service accounts permissons, because the cluster shares work on one
node but when I do a failover to the other node when users access the
shares they get access denied.

[Chuck [MSFT]]

If you configured share permissions in Explorer, you may see this behavior
because that is a local definition of permissions. You must configure share
permissions in the Cluster Administrator snap-in.
--
Chuck Timon, Jr.
Microsoft Corporation
Windows Server 2008 Readiness Team
This posting is provided 'AS IS" with no warranties, and confers no rights.

Post by m***@gmail.com
The cluster shares were working fine before adding the new resource
groups, I'm wondering whether something was messed up with the cluster
service accounts permissons, because the cluster shares work on one
node but when I do a failover to the other node when users access the
shares they get access denied.

[m***@gmail.com]

Chuck,

Thanks for the reply, I may have not mentioned the problem clearly.

Initially I had two resouces groups with File Shares configured with a
2Node cluster which were working fine, users could access regardless
of which node they were on.

However after adding a new resource group and configuring the new file
shares I found that the shares on my old resource groups gave an
access "denied error" whenever I did a failover to nodeA but the
shares are fine on nodeB.

I'm sure the security settings on the "File Share" are fine because I
didn't make any changes to the old resource groups, I only created a
new one, but after that whenever I do a failover to nodeA the File
Share resouces in all the resouce groups display "access denied" when
users try to access it.

[John Toner [MVP]]

You might want to try tweaking the security settings on the cluster
fileshare, just in case. Since you can access it on one node and not the
other, sounds like cluster file share security settings are off.

Regards,
John

Visit my blog: http://msmvps.com/blogs/jtoner

Post by m***@gmail.com
Chuck,
Thanks for the reply, I may have not mentioned the problem clearly.
Initially I had two resouces groups with File Shares configured with a
2Node cluster which were working fine, users could access regardless
of which node they were on.
However after adding a new resource group and configuring the new file
shares I found that the shares on my old resource groups gave an
access "denied error" whenever I did a failover to nodeA but the
shares are fine on nodeB.
I'm sure the security settings on the "File Share" are fine because I
didn't make any changes to the old resource groups, I only created a
new one, but after that whenever I do a failover to nodeA the File
Share resouces in all the resouce groups display "access denied" when
users try to access it.

[m***@gmail.com]

I just checked the permissions they are the same when I look on the
server regardless of which node the resources sit on the NTFS and
Share permissions look the same and on the physical server I can
access the shares.

Its just when it fails over to nodeA the file shares give an "access
denied", but on nodeB the file shares are functioning fine. However I
can access the drives without issues if I log on to either node
physically so I really stuck for what the cause of the issue is.

I've looked at the GPO settings and its all fine

[Edwin vMierlo [MVP]]

Post by m***@gmail.com
I just checked the permissions they are the same when I look on the
server regardless of which node the resources sit on the NTFS and
Share permissions look the same and on the physical server I can
access the shares.

Tell us:

1) did you use explorer to check ?
OR
2) did you use Cluster Administrator to check ?

Please let us know how exactly you checked the permissions !

[m***@gmail.com]

Hi Edwin,

I've checked using both tools; in

Cluster Manager I looked at the file share resources and confirmed the
Resource - Parameters - Permissions tab that the Share permissions
were correct (authenticated users - full control), then checked using
explorer the appropriate NTFS permissions were in place and regardless
which node the resources were sitting on the permissions were correct.

So thats the reason I'm really stumped with this issue, I've also
checked accessing the administrative shares (using the domain admin
acct) for the cluster drives and the situation is the same when all
the resources are on NodeA (we get access denied) but when we move
them to NodeB its fine.

I've looked at the GPOs and I don't get any errors and also turned on
userenv.log to check and both servers are getting exactly the same
policy settings.

Is it possible there is something to do with the SAN switch config.
(excuse my ignorance), I can access the drives properly if I logon to
the physical machine its just when I try to do it from the network.

Strange thing is if all the resources are on NodeA and I logon to
nodeA I can write to the drives, but if I access the network drive via
the UNC path from NodeA it also gives access denied.


Many thanks

[Mark]

this may be a long shot, but when you say you can access the problem folders
on the local problem node are you mapping to the unc or just navigating to
the directories in explorer. Do you see the actual shares in Computer
management on the problem node? Could there be a duplicate share naming
scheme causing the problem. I have seen issues where there are duplicate
shares created on the cluster and when the resource is moved the share no
longer exists since the cluster will only allow a given share name to exist
once on the cluster. Also, the case where two share resources are on the
same node, ie, VS1\Share1 and VS2\Share2 are both on node1, clients
incorrectly map to VS1\Share2, which will work, but once you move VS2\Share2
to node2 it is no longer accessible because it is really VS2\Share2. Like I
said a long shot but I have had clients do this and complain the share is not
accessible.

Hope that helps.

Marl
--
Mark

Post by m***@gmail.com
Hi Edwin,
I've checked using both tools; in
Cluster Manager I looked at the file share resources and confirmed the
Resource - Parameters - Permissions tab that the Share permissions
were correct (authenticated users - full control), then checked using
explorer the appropriate NTFS permissions were in place and regardless
which node the resources were sitting on the permissions were correct.
So thats the reason I'm really stumped with this issue, I've also
checked accessing the administrative shares (using the domain admin
acct) for the cluster drives and the situation is the same when all
the resources are on NodeA (we get access denied) but when we move
them to NodeB its fine.
I've looked at the GPOs and I don't get any errors and also turned on
userenv.log to check and both servers are getting exactly the same
policy settings.
Is it possible there is something to do with the SAN switch config.
(excuse my ignorance), I can access the drives properly if I logon to
the physical machine its just when I try to do it from the network.
Strange thing is if all the resources are on NodeA and I logon to
nodeA I can write to the drives, but if I access the network drive via
the UNC path from NodeA it also gives access denied.
Many thanks

[Edwin vMierlo [MVP]]

I would agree with Mark, but Mark beat me to it ;-)

check all share names for unique names, and include sharenames on the nodes
on the local (non-clustered) disks as well !

rgds,
edwin.

Post by m***@gmail.com
Hi Edwin,
I've checked using both tools; in
Cluster Manager I looked at the file share resources and confirmed the
Resource - Parameters - Permissions tab that the Share permissions
were correct (authenticated users - full control), then checked using
explorer the appropriate NTFS permissions were in place and regardless
which node the resources were sitting on the permissions were correct.
So thats the reason I'm really stumped with this issue, I've also
checked accessing the administrative shares (using the domain admin
acct) for the cluster drives and the situation is the same when all
the resources are on NodeA (we get access denied) but when we move
them to NodeB its fine.
I've looked at the GPOs and I don't get any errors and also turned on
userenv.log to check and both servers are getting exactly the same
policy settings.
Is it possible there is something to do with the SAN switch config.
(excuse my ignorance), I can access the drives properly if I logon to
the physical machine its just when I try to do it from the network.
Strange thing is if all the resources are on NodeA and I logon to
nodeA I can write to the drives, but if I access the network drive via
the UNC path from NodeA it also gives access denied.
Many thanks

[m***@gmail.com]

I found the cause was a stupid setting on the problem node with McAfee
denying read/write to shares