This website use cookies to help you have a superior and more admissible browsing experience on the website.
Loading...
For many vSphere administrators, configuring the vCenter Server Appliance (VCSA) file-based backup to use an SMB share and encountering the “vCenter backup SMB not supported is frustrating. In this guide, we will analyze why this error happens and then help you fix it step by step.
Common Symptoms:
1. SMBv1 Dependency and Deprecation (the most common cause)
Early VCSA builds relied heavily on SMBv1 behavior unless SMBv2 was manually enabled. But Microsoft deprecated SMBv1 in 2014. It was then later removed from the default installation in Windows 10 version 1709 and Windows Server version 1709. When the target server refuses SMBv1, the protocol negotiation fails, and VAMI reports the “not supported” error.
2. Known vCenter version bugs
3. Stale CIFS mount points
An interrupted backup can leave orphaned mounts under /storage/remote/backup/cifs/. These block new backup attempts, and VAMI shows the error.
4. Configuration and permission mismatches
You can use the table below to match your received error message with the most likely root cause and the recommended resolution methods. Methods below can be applied to vCenter 6.7 U2+/7.x/8.x/VCSA deployment.
|
Error Message / Symptom |
Causes |
Recommended Fix |
|
“Location type SMB is not supported” |
SMBv1 disabled on file server |
Method 1 (Enable SMBv2/3 on VCSA) |
|
“SMB location is invalid” |
SMBv1 disabled or hostname resolution |
Method 1; verify FQDN usage |
|
“Path not exported by remote file system” |
FIPS mode enabled on vCenter 7.0 U3 |
Method 2 (Upgrade to 7.0 U3c+) |
|
NT_STATUS_NOT_FOUND in backup.log |
Short hostname used in backup location |
Use FQDN in backup settings (Method 4) |
|
NT_STATUS_ACCESS_DENIED in logs |
Insufficient service account permissions |
Grant full admin privileges on SMB share (Method 4) |
|
NT_STATUS_LOGON_FAILURE after 7.0 U3h upgrade |
DFS namespace; SMB client architecture change |
Use direct UNC path, not DFS referral (Method 4) |
|
Backup hangs or fails at random progress |
Stale CIFS mount from prior failed job |
Method 3 (Clear stale mounts) |
|
“Backup Manager encountered an exception” (8.0) |
Target disk space exhausted |
Free up disk space on SMB share |
|
Backup fails, NTP not configured |
Time skew > 5 minutes between VCSA and SMB server |
Configure NTP on vCenter (Method 4) |
Key log file locations for diagnosis:
The SMB protocol incompatibility can be the most common causes. Many older VCSA builds historically relied on SMBv1 behavior unless SMBv2 support was explicitly enabled. However, modern Windows Server and NAS systems often disable SMBv1 for security reasons. As a result, the VCSA backup process may fail to negotiate a compatible SMB protocol version. Enabling SMBv2 support on the VCSA can often resolve the issue.
Step 1. SSH into the VCSA and enable the Bash shell:
shell.set --enabled true
shell
Step 2. Check the current SMBv2 registry value (optional, for verification):
/opt/likewise/bin/lwregshell list_values '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]'
The Smb2Enabled value should be 0 (disabled) by default
Step 3. Enable SMBv2 by setting the registry key
if the key does not yet exist:
/opt/likewise/bin/lwregshell add_value '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]' Smb2Enabled REG_DWORD 1
If the key already exists:
/opt/likewise/bin/lwregshell set_value '[HKEY_THIS_MACHINE\Services\lwio\Parameters\Drivers\rdr]' Smb2Enabled REG_DWORD 1
Step 4. Restart the likewise I/O service:
/opt/likewise/bin/lwsm restart lwio
Step 5. Verify SMB connectivity to your backup server:
/usr/bin/smbclient -L //<FQDN-of-SMB-server>/ -U <username>
If the connection succeeds, the VCSA is connected to SMBv2 or SMBv3.
Step 6. Run the backup from VAMI (https://<VCSA-IP>:5480) again and confirm it completes successfully. If vCenter SMB backup still fails, check /var/log/vmware/applmgmt/backup.log for detailed SMB handshake errors.
If you are on vCenter 7.0 U3 (pre-U3c) with FIPS mode enabled, or if you are experiencing the DFS namespace issue introduced in 7.0 U3h, a version upgrade resolves the problem cleanly.
Applicable upgrades:
|
Current Version |
Upgrade To |
Bug Fixed |
|
7.0 U3 — 7.0 U3b |
7.0 U3c or later |
FIPS-mode SMB backup failure (KB 318185) |
|
7.0 U3h+ with DFS |
7.0 U3o+ or 8.0 U1+ |
Kerberos DNS TXT packet limitation |
|
8.0 U2 |
8.0 U2d+ or 8.0 U3 |
Short-hostname resolution issue |
Step-by-step:
Step 1. Download the appropriate ISO from Broadcom Customer Connect (support.broadcom.com).
Step 2. Mount the ISO to the VCSA via the vSphere Client or out-of-band management.
Step 3. Navigate to VAMI (https://<VCSA-IP>:5480), go to Update, and stage/install the update.
Step 4. After the upgrade completes and the VCSA reboots, verify the build number and re-run the backup.
In some cases, vCenter backup failures occur because the previous SMB mount session was not properly released. VCSA may keep stale CIFS mount information even after the backup job fails, causing subsequent backup attempts to return errors such as:
– SMB location is invalid
– Backup Manager encountered an exception
– Failed to connect to SMB location
– Path not exported by remote filesystem
Removing the old SMB mount and reconnecting the share can often resolve the issue.
Step 1. Connect to the VCSA via SSH
Enable SSH on the VCSA if it is not already enabled.
Then connect using SSH:
ssh root@your-vcenter-server
After login, launch the Bash shell
shell
Step 2. Before unmounting anything, first identify the actual SMB mount path currently used by VCSA.
run:
mount | grep cifs
Example output:
//backupserver.company.local/vcsa-backup on /storage/remote/backup/cifs/52f3d2d8 type cifs <p ">The mount directory may contain dynamically generated IDs instead of the SMB share name. Do not assume the path is fixed.
Step 3. Use the mount path returned in the previous step.
Example:
umount /storage/remote/backup/cifs/52f3d2d8
If the mount is busy or stuck, force unmount it:
umount -f /storage/remote/backup/cifs/52f3d2d8
You can verify the mount was removed successfully:
mount | grep cifs
No output means the SMB mount has been cleared.
Step 4. Restart the appliance management service to refresh backup sessions:
service-control --restart applmgmt
Wait several minutes for the service to fully restart.
Then return to the VAMI interface and reconfigure the SMB backup job.
If the above methods do not resolve the “vCenter backup SMB not supported” issue, verify these configuration items:
● Use FQDN, not short hostname:
When entering the backup location in VAMI, always use the fully qualified domain name (e.g., //backupserver.yourdomain.local/share), never a short hostname (e.g., //backupserver/share). This is mandatory for vCenter 8.0 U2 and later, but is a best practice for all versions.
● Grant full admin privileges to the backup service account:
The account used to authenticate to the SMB share must have write and delete permissions. Broadcom recommends using an administrator account or a user with full admin privileges on the backup directory.
● Synchronize NTP:
Verify time synchronization between the VCSA and the SMB server:
ntpq -p
If NTP is not configured on the VCSA, configure it via VAMI: Networking > Time > Edit. The time offset between the VCSA and the SMB server must be under 5 minutes for Kerberos authentication to succeed
● Avoid DFS namespaces (7.0 U3h+):
If you are on vCenter 7.0 U3h or later and use a DFS namespace as your backup target, switch to the direct UNC path of the actual file server (e.g., //server01.domain.local/share instead of //domain.local/namespace/share)
Some users will re-enable SMBv1 as a quick fix, but do it on the backup server, not in production.
SMBv1 lacks encryption, mutual authentication, integrity checks, and protection against man-in-the-middle attacks. The EternalBlue exploit (CVE-2017-0144) specifically targets SMBv1 and was the primary vector for the WannaCry ransomware outbreak that affected hundreds of thousands of systems globally.
Microsoft deprecated SMBv1 over a decade ago, and every major security compliance framework (CIS, NIST, Cyber Essentials) mandates that it be disabled. Even in isolated lab environments, re-enabling SMBv1 normalizes a dangerous practice. The correct approach is to configure the VCSA to use SMBv2 or SMBv3, or switch to a more secure protocol entirely
If vCenter SMB backup is still not working after trying all the methods above, consider switching to one of these officially supported protocols. Each has distinct advantages:
|
Protocol |
Security |
Performance |
Best For |
|
FTPS (Explicit) |
TLS encryption; certificate-based auth |
Fast |
Environments with existing FTP infrastructure; works through proxies |
|
NFS |
Kerberos (v4) or IP-based ACLs |
High; native Linux protocol |
Homogeneous VMware/Linux shops; avoids all SMB compatibility issues |
|
SFTP |
SSH encryption; key-based auth |
Moderate (SSH overhead) |
Cross-site backups; firewall-friendly (port 22) |
|
HTTPS (WebDAV) |
TLS encryption; certificate-based auth |
Moderate |
Environments with existing web server infrastructure |
vCenter officially supports seven backup protocols: FTP, FTPS, HTTP, HTTPS, SFTP, NFS, and SMB.
NFS is often the most reliable alternative for VMware environments because it is native to Linux (which the VCSA runs) and does not involve the SMB protocol stack at all. If you have an NFS server (or a NAS that exports NFS shares), configuring it as your vCenter backup target eliminates the SMB protocol issue entirely.
FTPS (FTP over explicit TLS) is another strong choice for Windows-centric environments. It provides encrypted transport without the protocol-version compatibility headaches of SMB.
While VAMI‘s built-in file-based backup is adequate for protecting vCenter configuration, it has significant limitations: it does not protect your virtual machines, it lacks enterprise features like deduplication and centralized management, and it exposes you to protocol-level issues like the SMB error this article addresses.
For organizations managing multiple vCenter instances or seeking a comprehensive data protection strategy, Information2 (Info2soft)’s i2Backup offers a more robust way:
Now you can click the download button to request a 60-day free trial.
The “vCenter backup SMB not supported” error persists because of a fundamental protocol mismatch: the VCSA‘s legacy SMB client defaults to SMBv1, while modern file servers disable SMBv1 for security reasons. Add in FIPS-mode bugs, DFS namespace incompatibilities, stale mount points, and DNS misconfigurations.
The fastest path to resolution is:
A broken vCenter backup is not something to postpone—your vCenter configuration (inventory, roles, permissions, distributed switch settings) is critical infrastructure. Without a working backup, a vCenter failure can mean days of manual reconstruction. In addition, to backup all VMware guest VMs easily, you can use Info2soft’2 i2Backup.