Data Not Accessible After Failover

Introduction

If a failover reports success but clients cannot reach data on the target cluster, work through the checks in this article in order. Most cases are resolved by the first few checks, which cover the most common causes of a blocked mount after failover.

Quick Checks for Access Zone or IP Pool Failover

Follow these steps in order to find the root cause quickly.

1. Reboot the client first. Before testing further, reboot the PC or client used to test share access. Many apparent access failures are actually a cached connection or cached credential on the client, not a failover issue.
2. Check for a read-only source cluster error. If the client returns a write failure indicating the share is read-only, the client is still connected to the source cluster, which is locked by SyncIQ. Reboot the client and test again so it picks up the new DNS resolution.
3. Check the network path to the target cluster. Confirm a firewall or network device is not blocking the SMB protocol between the test client and the target cluster.
   • From a PowerShell prompt on the test client, run Test-NetConnection -ComputerName "<FQDN SmartConnect name>" -Port 445, replacing the FQDN with the SmartConnect name used to mount the share.
   • A successful test returns TcpTestSucceeded: True.
   • If the test fails, escalate to your network/firewall team to resolve the blocked port before continuing.
4. Check DNS and SmartConnect resolution. Ping the FQDN SmartConnect name (never use the short name) and confirm the IP address returned belongs to the target cluster.
   • If the name fails to resolve, continue with the detailed DNS steps below.
   • If the IP address is correct, continue with the next step.
5. Check for an authentication prompt when mounting. If mounting the share (DFS or non-DFS) prompts for a username and password, this usually indicates a missing Active Directory Service Principal Name (SPN) on the target cluster's AD computer object.
   • Use ADSI Edit to verify that HOST/<FQDN SmartConnect name> is present on the SPN property of the target cluster's computer account.
   • Enter an administrator account at the prompt to confirm data access works before correcting the SPN, to isolate whether the SPN is the only outstanding issue.
6. If none of these checks resolve the issue, continue with the detailed steps below for the relevant failover mode.

Detailed DNS and SmartConnect Debugging (Access Zone or IP Pool Modes)

Use nslookup to confirm SmartConnect names failed over correctly and that dual DNS delegation is configured correctly. This also rules out issues with your internal DNS resolvers.

Source cluster DNS test:

1. From a Windows client, open a command prompt and type nslookup.
2. Type server <source cluster Subnet Service IP>.
3. Type the FQDN of the SmartConnect zone used in the failover. Refer to the Failover Wizard failover log for the full list of SmartConnect names that were failed over.
4. The expected result is a failed resolution (for example, server can't find <name>: REFUSED) — this confirms the source cluster's DNS response has been disabled and clients cannot receive an IP address from the source cluster.
5. If the lookup does not return a refused/failed response, the SmartConnect name did not fail over correctly. Follow the networking recovery steps in Failover Recovery to correct the SmartConnect zone name or alias.

Target cluster DNS test:

1. Type server <target cluster Subnet Service IP>.
2. Type the FQDN of the SmartConnect zone used in the failover.
3. The expected result is a successful resolution returning the target cluster's IP address, confirming SmartConnect failed over correctly.
4. If this test fails, returns no IP address, or returns the wrong IP address, follow the networking recovery steps in Failover Recovery.
5. Double-check dual delegation:
   • From nslookup, type set type=ns, then type the FQDN SmartConnect name.
   • You should receive two name server records in the response — one for the source cluster's Subnet Service IP and one for the target cluster's Subnet Service IP.
   • If you do not receive both records, dual DNS delegation is not configured correctly in your internal DNS. Escalate to your DNS administrator to correct the delegation before retesting data access.

Detailed Steps for DFS Failover Mode

1. From a Windows client joined to Active Directory, mount the DFS folder (for example, \\<domain name>\<DFS root name>\<DFS folder name>).
2. Verify write access by creating a test file. If this succeeds, no further action is needed.
3. If the mount or write test fails:
   1. Log in to the source cluster and verify the SMB share used for the DFS referral UNC path has been renamed with the igls-dfs- prefix. If the prefix is missing, add it manually and save the share, then retest.
   2. If the write test still fails, log in to the target cluster and verify the corresponding SMB share does not have the igls-dfs- prefix. If it does, remove the prefix and save the share, then retest.
   3. If shares repeatedly fail to rename, contact support for the complete list of SMB shares that failed to rename during the failover so each can be corrected.
4. If the rename check does not resolve the issue, verify the DFS folder configuration in the DFS Management snap-in:
   1. Confirm both DFS referrals point to the source and target cluster SmartConnect names, using the same share name shown in your DFS folder configuration.
   2. Confirm referrals always use the FQDN SmartConnect name — never a short DNS name.
   3. Test each referral's UNC path directly from a Windows client (for example, \\dr.example.com\share). Confirm the share mounts, data is visible, and you can write to it.
   4. If a direct referral mount fails, return to the DNS and SmartConnect debugging steps above to confirm SmartConnect and DNS are configured correctly, then retest.

info

Starting in release 2.0, Eyeglass retries a failed share rename automatically, reducing the likelihood of encountering this scenario.

Detailed Steps for NFS Export Remount (Access Zone, IP Pool, or SyncIQ Mode)

NFS exports must be remounted on the Linux host so it resolves the SmartConnect name to the target cluster's IP address.

1. Unmount the export, forcing if a file is currently open: umount -fl <export-path>
2. Re-read /etc/fstab and remount any export that is not already mounted: sudo mount -a
3. If a mount error occurs, review the returned error message for the cause.
4. Run mount and confirm the IP address shown for the export belongs to the target cluster. If it does not, follow the DNS and SmartConnect debugging steps above.
5. Test write access:
   1. Change to the mount point defined in /etc/fstab (for example, cd /mnt/appdata).
   2. Run touch test.txt. This should complete without error.
   3. If a read-only filesystem error is returned, DNS is still resolving to the source cluster — follow the DNS and SmartConnect debugging steps above.
   4. Confirm the file was created with ls test.txt, then remove it with rm test.txt.

warning

If the target path used for the SyncIQ policy differs from the source path (for example, source /ifs/data/export replicated to /ifs/data/dr/export), the host's mount path must be updated to match the target path. To avoid this extra step, keep the target path the same as the source path when creating the SyncIQ policy.