vSAN File Service is in an unhealthy state and continuously poling for it's current configuration after an upgrade.

Products

• VMware vSAN

Issue/Introduction

• After upgrading the vSAN environment vSAN File Service is in an unhealthy state and continuously poling for it's current configuration
• vSAN RDMA and or vSAN Data Protection is enabled
• vSAN File Service may report either the error "Unable to extract requested data. Check vSphere Client logs for details" or continuously loop trying to display the current configuration:
  
  
  
  
• vSAN Health Service will report vSAN File Service Alerts
  
  
  
• vCenter Recent Tasks will show the FSVMs in a boot loop with the error "Cannot complete the operation. See the event logs for details. Failed to upgrade file service on host."
  

Environment

VMware vSAN 8.x
vSAN File Service
vSAN RDMA
vSAN Data Protection

Cause

When vSAN RDMA and /or vSAN Data Protection (also known as Snap Service) is enabled with vSAN File Service, the vdfsd-proxy fails to query the cluster Data in Transit (DIT) encryption state, then setting TLS to 1, resulting in vSAN File Service failing to re-enable properly after the upgrade.

vdfsd-proxy.log will contain the below messages

2026-07-03T07:37:46.061Z|f-0-000000000|VsanInfoImpl: Cr(26) vdfsd-proxy[13109521]: Refresh failed: Unable to complete Sysinfo operation.  Please see the VMkernel log file for more details.: Sysinfo error: Access denied by vmkernel access control policy See VMkernel log for details.

2026-07-03T07:37:46.061Z|f-0-000000000|PROXY:SetTLSOpt: Er(27) vdfsd-proxy[13109521]: Failed to get DIT encryption state: Unable to complete Sysinfo operation.  Please see the VMkernel log file for more details.: Sysinfo error: Access denied by vmkernel access control policySee VMkernel log for details.   <<<<<<<<<  CANNOT GET DIT encryption state (1)
 
2026-07-03T07:37:46.061Z|f-0-000000000|PROXY:SetTLSOpt: No(29) vdfsd-proxy[13109521]: TLS parameter has been set to 1   <<<< TLS is set to '1'

Resolution

vSAN Engineering is aware of this issue and working on a fix for future release.

Workaround

If the environment was already upgraded and vSAN File Service is in an unhealthy state

1. SSH to all hosts in the cluster and run esxcli system secpolicy domain set -l warning -n vdfsProxyDom (This will allow the vdfsd-proxy to get the correct cluster encryption status.)
2. Restart the vdfsd-proxy by running pkill vdfsd-proxy on all hosts to get the correct cluster encryption status
3. Wait a few minutes and vSAN File Service will return to a normal state.
4. Check vdfsd service by running /etc/init.d/vdfsd status

Note: The command in step 1 is not persistent across reboots. So if a host should reboot the workaround will need to be reimplemented. 

If further assistance is required open a case with vSAN Support.