Problem description
When configuring NAS Data Protection via the Druva Enterprise Workload Agent, proxy deployment failures, authentication timeouts, or unexpected scan degradation may occur. Specifically, environments may experience situations where the high-speed Advanced Smart Scan engine fails to initialize, forcing the agent to gracefully fall back to a traditional, time-intensive folder walk optimization method.
Typical symptoms encountered during deployment or backup cycles include:
Authentication timeouts or connection drops during NAS proxy pool assignment sequences.
Advanced Smart Scan failing to initialize despite the destination SMB share utilizing dialect 3.1.1.
Recurrent SMB handshake failures when interfacing with high-availability enterprise storage arrays (e.g., Pure Storage).
Cause
Deep log analysis and localized network packet captures indicate two isolated root causes originating from client-side network infrastructure and storage array behaviors:
NTLMv2 Enforcement & GPO Restrictions: Strict Active Directory Group Policy Objects (GPOs) governing allowed authentication layers block the initialization handshake between the proxy and the NAS array, resulting in localized Windows system errors (such as
Event ID 1825).Advanced Smart Scan & Continuous Availability (CA) Limitations: Certain enterprise storage architectures leverage Continuous Availability (CA) properties on their SMB shares. Druva's Advanced Smart Scan utilizes specific change-tracking API calls that present explicit vendor limitations when interacting with CA-enabled shares on certain arrays, blocking the optimized fast-scan method.
Resolution
Depending on your operational timeline and array layout, apply one of the following management paths:
Option A: Utilize the Native "Folder Walk" Fallback
If the affected storage volume is planned for data migration, decommissioning, or if modifying share architecture is prohibited by internal policy, no immediate system change is required. Druva is built to automatically switch to a standard folder walk whenever Advanced Smart Scan cannot query change states. Data validation, backups, and snapshot retention integrity will remain entirely secure and complete.
Option B: Adjust GPO and Credential Mappings for NTLMv2
For persistent long-term storage configurations suffering from handshake drops:
Collaborate with your Active Directory or Domain Administration team to verify GPO restrictions surrounding NTLM authentication parameters on the proxy server.
Test setting explicit security exceptions or allow-list rules for the dedicated IP addresses of your Druva NAS proxy servers.
Ensure that the service account mapped to the Druva agent holds explicit, un-inherited read/write permissions directly on the target storage volume.
If domain-level resolution continues to fail, alternate the credential syntax within the Druva Management Console between User Principal Name (UPN) format (
user@domain.com) and Down-Level Logon Name format (DOMAIN\user)..
Verification
To confirm that changes have remediated initialization blockages:
Validate Connectivity: Manually map the UNC path of the SMB target directory directly onto the proxy host machine using the exact designated backup service account to confirm raw path routing.
Execution Check: Run an on-demand manual backup set execution via Management Console > Protect > NAS > Backup Sets > Backup Now.
Log Audit: Open the latest job report details or local agent logs to verify that authentication passes successfully and that the backup sequence progresses cleanly without trailing network errors.