Known issues and limitations

You can review known issues, service limitations, and workarounds for Google Cloud NetApp Volumes to help you troubleshoot errors across general volume operations, Active Directory integration, customer-managed encryption keys (CMEK), volume replication, large capacity volumes, and FlexCache.

General issues

This section describes common known issues of NetApp Volumes.

Non-RFC 1918 (PUPI) client IP address support issues with Flex Unified service level

Issue: The Flex Unified service level doesn't support non-RFC 1918 (PUPI) client IP addresses.

Reason: This limitation is due to firewall rule constraints within the VSA tenant project.

Solution: To resolve this issue, consider the following options:

• Assign RFC 1918 IP addresses: Configure your clients to use RFC 1918 private IP addresses.

• Use a different service level: Use a service level that supports PUPI client IP addresses, such as Standard, Premium, Extreme, or Flex File.

• Request a manual firewall configuration: As a temporary workaround, you can contact Google Cloud Customer Care to manually set up firewall ingress rules for your PUPI client range. Note that manual configuration might require ongoing support efforts. To proceed with this option, submit a support request with the following information:

  • Your client PUPI IP range (for example, 100.64.0.0/10)

  • Required protocol ports (NFS, SMB, or iSCSI)

  • The target region and storage pool name

Not found errors when running backup operations after volume creation

Issue: If you run backup operations such as CreateBackup, RestoreVolume, or UpdateBackupConfig immediately after you create an ONTAP-mode volume, the operations can fail with a Not found error.

Reason: After you create a volume, the volume and its resources related to backup can take a short time to become fully available to the backup service. During this propagation period, the backup service might route backup requests before the volume is discoverable, which results in a Not found error.

Solution: Wait at least three minutes after you create the volume before running backup-related operations.

Flex File volumes don't respond to ping

For more information about this issue, see Test connectivity to NetApp Volumes.

Intermittent connectivity loss when using overlapping Private Services Access connections

When you configure private services access for the netapp.servicenetworking.goog connection, if the CIDR range overlaps with the CIDR range used by another private services access connection on the same Virtual Private Cloud (VPC), it can result in intermittent connectivity loss of the volume mount connection. Use non-overlapping ranges to avoid this problem.

Possible disruption of client access to volumes transitioned from Cloud Volumes Service to NetApp Volumes when updating settings of an NFS volume

Issue: There is a disruption of client access to volumes when you update any settings on either the source or destination volume of an active volume replication with a mirrored transfer status.

Reason: Updating a volume can lead to synchronization of its export policy with the replication partner volume. If the updated volume has an incorrect or missing export policy, the clients mounted to the production source volume might lose access, potentially causing an outage.

Background: When a replication is in a mirrored state, NetApp Volumes automatically synchronizes the export policies of the source and destination volumes. This synchronization ensures consistent client access without manual administrator intervention, because any policy change on one volume is automatically applied to the other volume.

In Cloud Volumes Service (CVS), the administrator needs to manually synchronize the source and destination volume settings. During the volume transition from CVS to NetApp Volumes, the existing export policies were transferred without modifications, which can lead to inconsistent export policies in replicated volumes. When you update the export policy of either the source or destination volume in a volume replication relationship, NetApp Volumes automatically synchronizes the policies on both volumes.

Affected volumes:

This issue applies to volumes that meet all of the following criteria:

• Volumes that are in an active, mirrored volume replication. Resuming the replication after it's stopped can cause the issue.

• All NFS-enabled volumes that have an export policy.

• Volumes where the export policy differs between the source and destination.

Solution: To resolve this issue, the export policy of source and destination volumes must be synchronized once. Complete the following steps:

1. Examine and compare the export policies of both the source and destination volumes.

   • If the export policies are identical, no action is required.

   • If the export policies are different, merge the export rules to create an export policy that allows all hosts specified in both policies.

2. Apply the merged export policy to the source volume. This policy is also automatically applied to the destination volume.

By synchronizing the export policies, you can ensure consistent access and prevent potential disruptions to clients.

Error message when using Cloud Volumes Service (CVS) and NetApp Volumes resources together

You might get an error message about using CVS and NetApp Volumes resources together within a VPC, project, or region. This issue can occur when you try to create resources such as pools and policies if either of the following is true for the project:

• The project was previously used for CVS.

• A CVS resource list operation was performed in a project that has no NetApp Volumes resources.

The following are the common error messages:

• Host project and service project must be using the same service.

• Resources from CVS and NetApp Volumes may not be used together in a single region.

• Cannot share VPC between 3P and 1P networks.

To resolve this issue, contact Google Cloud Customer Care and request a reset of your specific projects or regions to exclusively use NetApp Volumes resources.

File creation fails with No space left on device or File too large errors in a specific directory

Issue: When attempting to write, copy, or create new files or subdirectories on a mounted volume, the operation fails with either a No space left on device (errno 28 / ENOSPC) or a File too large (errno 27 / EFBIG) error.

This error occurs even when client-side disk space queries (such as df -h) and the Google Cloud console show that the volume has plenty of available logical capacity. The error is localized to a specific directory; file creation succeeds in other directories on the same volume.

Reason: This issue occurs when a single directory grows excessively large and hits internal limits, preventing the storage system from indexing more files or subdirectories in that specific location.

Verification:

Verify if you have hit directory size limits by performing the following diagnostic steps on a mounted client:

1. Test localized file creation: Attempt to create a file in a completely different, newly created directory on the exact same volume: bash mkdir /mount_point/test_dir && touch /mount_point/test_dir/test_file.txt If this command succeeds but writing to the original directory fails, the directory limit has likely been reached.

2. Estimate directory entry counts: Count the number of entries inside the offending directory: bash find /mount_point/offending_directory -maxdepth 1 | wc -l

3. Inspect directory index file size: Check the directory's metadata footprint: bash ls -ld /mount_point/offending_directory An exceptionally large directory file size indicates massive directory metadata bloat.

Solution:

To resolve this issue and keep your directory structures healthy, implement the following methods:

• Implement directory sharding: Restructure your application or workload to distribute files across nested, hierarchical subdirectories (such as /aa/bb/filename.txt instead of keeping massive numbers of files in a single flat directory).

• Rebuild bloated directories: Simply deleting files from an over-limit directory removes their names but doesn't automatically shrink the physical size of the directory index file in the underlying file system. To fully reclaim the directory's space, copy or move the active files into a new directory, and then delete the old, bloated directory.

Active Directory integration issues

The following sections contain known issues of Active Directory integration.

Connectivity issues

Connections to on-premises domain controllers fail due to the following limitations:

• VPC peering: NetApp Volumes can only reach domain controllers that are on the storage pool's VPC or are connected to it by VPN. NetApp Volumes can't reach domain controllers in any other VPC, including those that are peered to the storage pool's VPC and that connect to the storage pool.

• Firewalls: The on-premises connection fails if you don't allow NetApp Volumes to contact your domain controllers. For more information, see Firewall rules for Active Directory access.

Modifying the Active Directory site setting of an Active Directory policy doesn't affect Flex File service level storage pools. This setting works for Flex Unified pools.

NetApp Volumes can't join Windows 2025 based domain controllers

Due to a regression in Windows 2025, NetApp Volumes can't join a domain using a Windows 2025 domain controller.

As of September 9, 2025, Microsoft has released KB5065431 and KB5065426 to address this issue. Windows 2025 doesn't support RC4 encryption, so you must Enable AES Encryption for Active Directory authentication.

For more information, see Domain controller communication with Windows 2025 or earlier versions can fail due to enforcement of SMB 3.1.1.

Domain controller communication with Windows 2025 or earlier versions can fail due to enforcement of SMB 3.1.1

Windows 2025 domain controllers enforce SMB 3.1.1 for communication with Active Directory clients. The Center for Internet Security (CIS) Policy 18.6.7.6 also recommends using SMB 3.1.1 for earlier Windows versions.

Although NetApp Volumes supports SMB 3.1.1 for communication between SMB clients and the NetApp Volumes SMB server, it supports only SMB 2.1 and SMB 3.0 when connecting to Active Directory as a client.

If domain controllers allow only SMB 3.1.1 connections, NetApp Volumes can't connect to Active Directory, which causes service disruptions.

To maintain compatibility, set SMB 2.1 as the minimum supported SMB version on your domain controllers. You must apply this setting to all domain controllers, or to every domain controller in the Active Directory site if you use site-based Active Directory policies.

The following example shows how to set the minimum supported SMB version to 2.1:

 Set-SmbServerConfiguration -Smb2DialectMax SMB311 -Smb2DialectMin SMB210

For more information about modifying SMB settings using PowerShell or group policies, see Manage SMB dialects in Windows and Windows Server 2025.

LDAP connections to Active Directory fail after Microsoft October 2026 domain controller updates

Issue: After you install the Microsoft October 2026 security updates on your Active Directory domain controllers, the storage pools and volumes connected to Active Directory can't complete an LDAP bind to those domain controllers. As a result, you might encounter errors when connecting to SMB shares, adding users to shares, or using or testing a new Active Directory policy.

Reason: The following Microsoft cumulative security updates modify LDAP connection behavior, which disrupts communication with NetApp Volumes:

• October 13, 2026—KB5126646 (Windows Server 2025)

• October 13, 2026—KB5126655 (Windows Server 2022)

• October 13, 2026—KB5126651 (Windows Server 2019)

• October 13, 2026—KB5126868 (Windows Server 2016)

NetApp tracks this issue in NetApp Support Bulletin SU628.

Solution: To resolve this issue on your domain controllers, either roll back the security updates or apply the registry edit workaround described in Access to NetApp SMB shares might fail after installing the October 2026 Windows security update.

Alternatively, if you use Flex Unified ONTAP-mode, you can configure LDAP session security on your storage virtual machines (SVMs):

• Before or after you patch your domain controllers, set LDAP session security to sign or seal on each affected SVM. Either value meets the requirement, though seal provides additional encryption for LDAP payload data:

  vserver cifs security show -fields session-security-for-ad-ldap
  vserver cifs security modify -vserver SVM_NAME -session-security-for-ad-ldap sign
  vserver cifs domain discovered-servers reset-servers -vserver SVM_NAME
  

• If an LDAP client configuration on the SVM binds as the CIFS server using vserver services name-service ldap client with -bind-as-cifs-server true, or binds to an Active Directory domain with -bind-dn and -ad-domain configured, set -session-security to sign or seal on that client configuration:

  vserver services name-service ldap client show -vserver SVM_NAME
  vserver services name-service ldap client modify -vserver SVM_NAME -client-config CONFIG_NAME -session-security sign
  

• Verify that Kerberos authentication works between the SVM and your domain controllers, which is required when using sign or seal. Your domain controllers must have resolvable forward (A) and reverse (PTR) DNS records. Missing or incorrect PTR records can cause the LDAP bind to fail with GSSAPI errors, such as Cannot determine realm for numeric host address or Server not found in Kerberos database.

• After you apply the changes, test the connection to confirm LDAP connectivity:

  set -privilege diag
  secd connections test -node NODE -vserver SVM_NAME
  

• Updating the session security setting doesn't require domain credentials or reset the Active Directory machine account password. Because LDAP is evaluated during bind and lookup operations, existing SMB client sessions remain connected.

• For NFS-only SVMs that use an LDAP client bound to Active Directory, also set -session-security to sign or seal on the LDAP client when applicable, including in environments that use LDAPS on port 636.

If your problem persists or you need assistance, contact Google Cloud Customer Care.

CMEK issues

The following sections contain known issues of customer-managed encryption key (CMEK) operations.

ListKmsConfigs returns Invalid value for enum type error

While a volume migrates from system-managed to customer-managed encryption, the ListKmsConfigs command occasionally returns an Invalid value for enum type error during migration. After the migration finishes, the ListKmsConfigs command returns to working normally.

KmsConfig policy creation fails

Occasionally, KmsConfig policy creation fails and blocks you from creating another policy. If this issue occurs, contact Google Cloud Customer Care.

Volume replication issues and limitations

The following sections provide details about known issues and limitations of the volume replication feature.

Destination volume quota settings might fail in an active replication

When modifying settings on a volume in an active replication, the settings are applied to both the source and destination volumes. However, quota changes specifically for destination volumes are staged and get applied to the destination volume after the replication is stopped. Occasionally, this quota setting might fail, and you receive an error message at the end of the operation. Although the Stop operation succeeds, all of the quotas might not have been applied to the destination volume. If you receive a quota error during a Stop operation, compare the quota rules on both the source and destination volumes and then update any missing quota rules on the destination to match the source volume settings.

Google Cloud console displays storage pools without associated Active Directory policies

In the Google Cloud console, when you create a volume replication for a source volume, the list of storage pools to choose from to create the destination volume contains storage pools that don't have an Active Directory policy. Selecting a storage pool without an Active Directory policy leads to replication failure.

Large capacity volumes known issues

The following section describes known issues of the large capacity volumes feature.

Incompatible pools displayed

When changing the storage pool (service level), the Google Cloud console might show incompatible pools. If you try to change to an incompatible storage pool, the attempt fails and you receive an error message.

CMEK migration not blocked

The Google Cloud console doesn't block CMEK migration when large capacity volumes are present. However, if you try CMEK migration when large capacity volumes are configured, the attempt fails.

FlexCache issues

This section describes known issues of the FlexCache feature.

FlexCache volume modifications in Google Cloud console might fail

You can modify FlexCache volumes only by using the API or the Google Cloud CLI. Although the Google Cloud console displays FlexCache volumes after creation and lets you view or delete them, any attempts to update them in the Google Cloud console might fail. In such cases, use the Google Cloud CLI or API for modifications.

FlexCache volume creation fails with snapshot-directory set to true

FlexCache volumes don't support the snapshot-directory option. Although the API sets this parameter to false by default, the Google Cloud CLI sets it to true by default. Therefore, when creating a FlexCache volume using Google Cloud CLI, you must explicitly include --snapshot-directory false to prevent creation failure.