Xen Orchestra - Permissions Issue - File level restore
-
I'm also seeing this.... fusermount issue but for a different backup.
Dec 20 16:40:09 xo-test-debian-3 xo-server[414]: Tue, 20 Dec 2016 21:40:09 GMT xo:api admin@domain.com | backup.scanDisk(...) [214ms] =!> Error: spawn fusermount ENOENT -
I wonder if any of the items described here apply to your situation?
-
Check to see if the path and file actually exist.
-
@Danp I'll take a look for the file first thing tomorrow when I'm back at the office, I have some errands I have to run this afternoon.
-
I don't have the VHD (20161214T030158Z_delta.vhd) listed from the 14th (it's at my rotation schedule) so that doesn't mean much...
Once the dates are fixed testing this will be a bit easier.
-
@DustinB3403 You could temporarily build from next-release.
-
@Danp yeah...
Guess I have too..
-
All backups are still listed as being created on January 17th 1970....
-
Post the output from the following command --
cd /opt/xo-server && git rev-parse --abbrev-ref HEAD -
@Danp 8827f8e940e0f0bc73230e772855640e6cbd8d27
-
@DustinB3403 Was expecting
stableornext-release. How did you perform the update? -
One sec, realized I was only on NR for xo-server and not xo-web, just did a checkout for web, and running the update.
-
There we go, now it's
cd /opt/xo-server && git rev-parse --abbrev-ref HEAD next-release -
Should have used the update script.
-
Building mine now on next-release to test
-
I do use the update script to perform the update, but you added flags didnt you... dang it I keep forgetting about those lol...
Anyways the file level backups still list 1970 as the creation date.
-
@DustinB3403 My dates are correct after rebuilding on next-release.
-
@Danp Hrm...
Mine are still clustered. . . .
-
Try with a force rebuild --
sudo curl https://raw.githubusercontent.com/Jarli01/xenorchestra_updater/master/xo-update.sh | bash -s -- -f -
@Danp Trying now
