I would try without the port, in every other system i've used I only had to specify the port if it wasn't the default. I would also try a non-hidden share in case it has an issue with that or the $ in the name
Thank you for the tips, but I was not successful.
I dumped the hidden share and just went by IP to avoid DNS. Tried backup location format:
I get "SMB location is invalid".
To keep it simple for now, I set the "Everyone" group on the share to Full Control. My account is local Admin on the server, so NTFS for my account is confirmed to have Full Control also. I confirmed the share is accessible from another Windows machine.
The example in the field has "/folder/subfolder". So I made a subfolder:
I have also tried the domain account formats domain\account and email@example.com.
Interestingly, I did another search online for this issue. This thread is the top 6 posts on Google. Nice.
I ran into the same thing. It seems that the SMB functionality is only compatible with SMB1. Try setting your destination to accept SMB1.
I'm personally sticking to FTP until this get's fixed as I'd rather not enable legacy SMB on my NAS for security reasons.
Thanks for that update.
Yeah, no way am I enabling SMB1.
Oh well. Hopefully they get it "fixed" with a less vulnerable version of the protocol.
Do not specify domain. Just type the account and password.
Also make sure SMB1 is enabled. VMware is working on a fix to make it work with SMB2.
Solved for me in latest version released July 15th. 220.127.116.11000
1 person found this helpful
cant get this to work in 18.104.22.168000 14070457
Error in method invocation module 'util.Messages' has no attribute 'ScheduleLocationDoesNotExist'
Error in Log:
2019-11-05T09:29:00.6 ERROR:backupRestoreAPI:Failed to mount the cifs share //SERVER/vCenterBackup/ at /storage/remote/backup/cifs/SERVER/kxqnbNRy/lTVZahRD; Err: rc=32, stdOut:, stdErr: mount error(112): Host is down
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
when trying a manual mount via shell on VCSA: mount -t cifs //SERVER/vCenterBackup /storage/remote/backup/cifs/ -o username=vCenter.Backup,vers=2.0
it works without any problems. Target Server is Windows Server 2019 with no SMB1 enabled.
is there still a need to enable SMB2 on VCSA?
Seems like a common problem with 6.7 as of now. I too tried SMB backups and could not. finally had to switch back to a FTP on windows box.
raised a Ticket yesterday and VMware still knows there is an issue with SMB2 and only SMB1 is working at the moment.
There is also no date when this will be finally fixed :-(
pity they didnt mention this in the known issue section in the release notes of VCSA
That's correct, SMB2 isn't working perfectly with VCSA file-based backup.
We have published a KB for that, you can refer to it here:
As mentioned in this KB, Engineering would fix this issue in a future release.
I found it working when I specify administrative share, for instance: SMB://server1/e$/vcbackup.
Of course a user must have admin access to the server serving backup folder. Not a nice way, but still better than enabling SMB1.
While the broken retain only feature was fixed in the December 2019 build (15132721), SMB support for >1.0 is still broken
Had this been resolved with vCSA 6.7 u3b ? Is there an update on the SMB v2 support?
I just upgraded both of my vCenters to 22.214.171.124000 and SMB2 is not working. Same failure as on 6.7.40000.