locked
Failover Cluster Validation Fails with SMB Share Access Error RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    The two-node cluster is set up and running without any problems as far as I can tell BUT: The cluster validation test gives this warning.

    Failed to validate Server Message Block (SMB) share access through the IP address of the fault tolerant network driver for failover clustering (NetFT). The connection was attempted with the Cluster Shared Volumes test user account, from node Hyper-V22.contoso.local to the share on node Hyper-V23.contoso.local. Access is denied.

    and

    Failed to validate Server Message Block (SMB) share access through the IP address of the fault tolerant network driver for failover clustering (NetFT). The connection was attempted with the Cluster Shared Volumes test user account, from node Hyper-V23.contoso.local to the share on node Hyper-V22.contoso.local. Access is denied.

    During the test, this error occurs in the SMBClient log of the node.

    169.254.1.88 is the address of the other node's Tunnel Failover Cluster Virtual Adapter.

    I cannot ping the remote node's Failover Cluster Virtual Adapter IP address. The firewall is off on all profiles. What is wrong here?

    Tuesday, August 27, 2019 4:51 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Thanks for your question.

    Cluster Shared Volumes uses SMB as a protocol transport between the nodes in the cluster.  Validate has a test which creates a share and verifies SMB connections between the nodes.  That test is failing...

    Please check this thread which is in a similar situation as yours, hope this helps.

    https://social.technet.microsoft.com/Forums/windows/en-US/663d7e78-8bee-4871-806f-7968f78df2b3/win-2012-storage-validation-warning-quotvalidate-csv-settingsquot-access-denied?forum=winserverClustering

    Phasisly check the following,

    - File Server feature is installed on all cluster nodes.

    - SMB server is enabled on all cluster nodes, and in particular server service is running on all the nodes

    - Verify that your firewall is not blocking SMB outgoing or incomming traffic. Make sure that rules would not block it for any network/IP.

    - Check if from one machine you can access \\<machine name>\c$ on the other machine.

    Finally, the poster turns out the problem by changing the following registry. Please try it to see if it works.

    They were disabling SMBv2 using

    Hive       HKEY_LOCAL_MACHINE

    Key path              SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

    Value name        smb2

    Value type          REG_DWORD

    Value data           0x0 (0)

    Besides, I observed that the node’s Tunnel Failover Cluster Virtual Adapter IP is APIPA address. Please check if this virtual IP in the cluster resource group set correctly.

    Hope above information can help you.

    Highly appreciate your effort and time. If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, August 28, 2019 6:07 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi thanks for you reply. Here goes:

    <File Server feature is installed on all cluster nodes.

    yes

    <- SMB server is enabled on all cluster nodes, and in particular server service is running on all the nodes

    yes

    < - Verify that your firewall is not blocking SMB outgoing or incomming traffic. Make sure that rules would not block it for any network/IP.

    Yes. The firewall is disabled for all profiles

    There are no registry keys or group policies that would disable SMB2

    APIPA address of the Failover Cluster Virtual Adapter: This is true and is correct as described here: https://blogs.technet.microsoft.com/askcore/2009/02/13/what-is-a-microsoft-failover-cluster-virtual-adapter-anyway/

    Finally, I can reach the other node's c$ share using all IP addresses and adapters and networks that are configured for the nodes but using the Failover Cluster Virtual Adapter ip addresses there appears to be communication at all between the nodes possible (Neither ping nor file shares).

    Locally it is working: On the node with 169.254.2.77 i can access \\169.254.2.77\c$ locally and on the other node it is \\169.254.1.88\c$ but not across the nodes.

    One question I have is: Is it normal behavior that you cannot ping or use file shares on the Failover Cluster Virtual Adapter's APIPA address?

    Wednesday, August 28, 2019 3:37 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Thanks for your detailed information.

    The Microsoft Failover Cluster Virtual Adapter has a MAC address and both IPv4 and IPv6 addresses assigned to it. The IPv4 address is an Automatic Private Internet Protocol Addressing (APIPA) address and the IPv6 address is a non-routable Link-Local address, but that does not matter as all cluster communications are tunneled through the networks supported by the physical NICs as shown here using the route information obtained during the cluster service startup.

    Whereas, APIPA addresses do not fall into any of the private IP address ranges defined by the Internet Protocol standard and are restricted for use on local networks only. Like private IP addresses, ping tests or any other connection requests from the internet and other outside networks cannot be made to APIPA devices directly.

    APIPA-configured devices can communicate with peer devices on their local network but cannot communicate outside of it.

    Therefore, while APIPA provides Windows clients a usable IP address, it does not provide the client with nameserver (DNS or WINS) and network gateway addresses as DHCP does.

    Highly appreciate your effort and time. If you have any question or concern, please feel free to let me know.

    Best regards,

    Michael

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, August 30, 2019 8:47 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    Just checking in to see if the information provided was helpful. Please let us know if you would like further assistance.

    Best Regards,

    Michael

    Please remember to mark the replies as an answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Tuesday, September 3, 2019 11:51 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    No, it didn't help. I'll try to sum up my issues and questions.

    1. Locally it is working: On the node with 169.254.2.77 i can access \\169.254.2.77\c$ locally and on the other node it is \\169.254.1.88\c$ but not across the nodes.

      Here it would be great if somebody who runs a cluster could confirm that they can use ping and SMB on their NETFT interface across nodes.

      I am also setting up  a test environment to try and confirm this behavior.
    2. Futher, all physical networks have connectivity between nodes, but the NETFT does not. At the same time the cluster seems to work just fine. How can the cluster even function if the cluster nodes can apparently not communicate with each other using the NETFT interface?
    3. The MAC address of the NETFT adpater: Accoring to the blog*, the MAC address should be similar to the actual physical adpater's address.

      In the example on the blog, it is like this:
      Physical NIC MAC is: 
      00-1A-A0-C2-1C-81
      NETFT MAC is 
      02-1A-A0-C2-1C-81

      Now, for my cluster:
      the physical NICs MACs are:
      A0-36-9F-AF-0F-B1
      A0-36-9F-AF-0F-B0
      00-1E-67-E0-A2-8B
      00-1E-67-E0-A2-8A

      NETFT MAC
      02-52-5A-05-15-42

      It looks like NETFT's MAC address is not derived from any physical adapter. This would also be great is somebody could look at how it is on their cluster. It seems to me this is wrong

      * https://blogs.technet.microsoft.com/askcore/2009/02/13/what-is-a-microsoft-failover-cluster-virtual-adapter-anyway/

    Tuesday, September 3, 2019 4:29 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    In the test environment, I am having the same issue. Not sure what I could do now.

    I set up a cluster with two nodes (testnode1, testnode2) and each node has only one network adapter.

    The initial validation tests succeed, and I used these results to build the cluster. Once the cluster is created, the validation fails with storage | Validate CSV Settings giving this error:

    “Validating access using Server Message Block (SMB) protocol from node testnode1.contoso.local to a share on node testnode2.symposionline.local.

    Failed to validate Server Message Block (SMB) share access through the IP address of the fault tolerant network driver for failover clustering (NetFT). The connection was attempted with the Cluster Shared Volumes test user account, from node testnode1.contoso.local to the share on node testnode2.symposionline.local. Access is denied.”

    In the SMB client log, this looks like:

    Failed to establish a network connection.

    Error: {Device Timeout}

    The specified I/O operation on %hs was not completed before the time-out period expired.

    Server name: 169.254.2.172

    Server address: 169.254.2.172:445

    Instance name: \Device\LanmanRedirector

    Connection type: Wsk

    Guidance:

    This indicates a problem with the underlying network or transport, such as with TCP/IP, and not with SMB. A firewall that blocks TCP port 445, or TCP port 5445 when using an iWARP RDMA adapter, can also cause this issue.

    Once again, the NETFT adapters cannot ping each other or use any other service like SMB.

    Thursday, September 5, 2019 2:45 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi PKersey,

    did you make any progress regarding this issue? I'm having the same issues you are having but i sadly still can't seem to find a proper solution to this topic. We could probably ignore the warning since everything else seems to be working fine but i'm still kinda worried that this issue will manifest somewhere else aswell.

    Best Regards,

    Dominik

    Monday, September 16, 2019 2:00 PM