Forum ©XSIBackup: ©VMWare ©ESXi Backup Software

Could be something related to your remote Linux distro we'll try to take a closer look at it and make extended tests with Ubuntu 20

We have just released v. 1.5.0.13. This issue should be solved for you, just let us know.

Thank you, we are constantly testing all features. The GUI is bash based, it works on top of the binary as a mere abstraction layer. We'll check the GUI in your very same build.

We published the bug.
The fix will be released tomorrow as 1.5.0.13 if all tests go well.
[url=https://33hops.com/forum/viewtopic.php?pid=4232#p4232]Bug on --rotate in some ESXi versions[/url]

Thanks to you for your patience.
This time of the year we are working half gas.
We have indeed detected some issue in this build (VMware ESXi 6.7.0 build-14320388).
We will release a fix ASAP. Please rotate manually until we do.

We are making tests with your same exact version this weekend, we'll reach you back as soon as we have something.

OK, let's concentrate on the main issue and we can then address the other one.
We'll try to reproduce the problem on the exact same version + build.

Well, it turned out to be something that we weren't expecting. This is the relevant part in the strace output.

read(10, "Bad port '-q'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 255) = 255

For some reason the ssh client is not taking the -q option (quiet), or the call is malformed.
This isn't happening on our tests though. Can you share the exact build number with [b]vmware -v[/b]?, so that we can try to install the very same build and again try to reproduce your issue.

Now the weirdest thing of all is that in theory (you didn't post the exact job command that produced the above strace output, we will asume it is the very same as in the previous post) the job was local, thus, there should not be any ssh command tunneling at that point.

Always post the output when requesting help, otherwise we have to guess all the data that is not there.

We can't reproduce your issue. Renaming the VM does not affect detecting and renaming files associated to the VM.
We just fixed a problem triggered by some faulty versions of OpenSSL in some older versions of (c)ESXi in branch 5 and early 6
Download 1.5.0.12 and try again. Let us know if that fixed your issue.

The problem is solved in 1.5.0.12 available in the download zone of the user area.
Please confirm whether this fixed your issue.

It could be, we have nonetheless reproduced your environment 5.5 to 6.5 without issue.
Post the output of

vmware -v

From both hosts and we will try to reproduce the exact same environment accurate to the build number.
In any case the problem is rather clear. From your strace.

pipe([10, 11])                          = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x32000910) = 524212574
close(11)                               = 0
fstat(10, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x3ffc0ec7000
read(10, sh: syntax error: unterminated quoted string
"", 600) 

The pipe command returns a shell syntax error that isn't happening in other builds nor in our tests. Everything points at some bug in the OpenSSH client.

This is the exact translated command that you can use to debug your scenario and the one that returns the first error. Run from your ESXi 5.5 host and post the output.

ssh -vvv -i xsibackup_id_rsa root@REDACTED "\"/scratch/XSI/XSIBackup-DC/xsibackup\" --free-space \"/vmfs/volumes/Backups/backups_ctec\""

(*) The -vvv will just make ssh client to be verbose.

The problem seems to be related to the double quote escaping, most probably the ssh client is not parsing them well, which would lead us to our very first answer: [b]patch your ESXi 5.5 host[/b].

If you want to make a quick test, just copy some ssh client binary from some close version, maybe the one packed in ESXi 6.0 should work. Still that would not survive a reboot, which would again lead you to the need to patch your host to the latest build in the 5.5 branch.

(c)XSIBackup uses system calls, the same as your manual commands. We haven't been able to reproduce your issue on the other side. If it was a bug I guess we would know by now as some other people would have complained on the same matter. We can't be sure 100% without checking it, it all looks like some sort of misconfiguration or faulty driver/ hardware though.

[b]No such file or directory[/b] is a message coming directly from the remote system call. It's not the same to delete a folder manually than doing it right after a heavy load on the NFS share.

Contact us directly to ask for a remote RDP session if you will, but please change your cables/ switch and try to find the problem on your own first.