Open marcsitkin opened 1 month ago
m3nu
commented
1 month ago Hard to understand your description, but here are 2 pointers on why 2 of your repos may be failing:
ssh://yse616m7@yse616m7.repo.borgbase.com/./repo: ERROR - Conditions for backup not met. Aborting. Could mean that you changed something in the allowed Wifi settings.PermissionError: [Errno 13] Permission denied: '/media/marcs/BackInTime/BORG-DATA_1'
marcsitkin
commented
1 month ago Thanks for your reply. I'm sorry you don't understand my description. To summarize, although Vorta displays a list of profiles, for many, the sources go missing, and the repo's are not listed to back up to . Seems like configurations are being destroyed.
Please let me know what other information I might provide you, and what I might try to rectify the situation.
Regarding allowed wifi settings. Where would these be? My internet connection is via ethernet cable, no wifi used on this computer. I've attached the latest log in case it's of any use. vorta.log
m3nu
commented
1 month ago ERROR - Conditions for backup not met. Aborting.
This means there is some issue in your setup and the backup can't start. Network is just one. Missing repo folder or Borg binary are others. See here: https://github.com/borgbase/vorta/blob/master/src/vorta/borg/create.py#L85
The log could be more detailed here.
marcsitkin
commented
1 month ago So is this not repairable? Should I switch to a different backup solution? Hardware problem maybe? Strange it has started after so long.
On Mon, Oct 21, 2024, 9:38 AM Manu @.***> wrote:
ERROR - Conditions for backup not met. Aborting.
This means there is some issue in your setup and the backup can't start. Network is just one. Missing repo folder or Borg binary are others. See here: https://github.com/borgbase/vorta/blob/master/src/vorta/borg/create.py#L85
The log could be more detailed here.
— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta/issues/2107#issuecomment-2426714733, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN64KKUIWEZ7XPYU5H74GO3Z4T7XBAVCNFSM6AAAAABQIXOSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRWG4YTINZTGM . You are receiving this because you authored the thread.Message ID: @.***>
m3nu
commented
1 month ago The local repo has permission errors. Those aren't necessarily hardware errors. I would check those permissions, as it says:
PermissionError: [Errno 13] Permission denied: '/media/marcs/BackInTime/BORG-DATA_1'
I don't see errors for your BorgBase repo. You can try using Borg directly to get a clearer error message. Maybe you're missing your Borg binary? E.g.
$ borg info ssh://yse616m7@yse616m7.repo.borgbase.com/./repo
sten0
commented
2 weeks ago Hi @marcsitkin, Thanks for reaching out! The errors @m3nu notes may have emerged from Flatpack (not the Vorta flatpack itself).
Are you able to navigate to /media/marcs/BackInTime/BORG-DATA_1, as the marcs user, with your file browser? Are you able to access the README in that directory?
Repology.org indicates that Vorta 0.9.1 is available in "MX Linux MX-23 Testing", so maybe you could try that? MX community support channels should be able to help you enable that repository. It also has Borg 1.4.0 ("borgbackup" package).
marcsitkin
commented
2 weeks ago Hi- I'm currently using the flatpak version 0.91 from flathub. I back up to repo's on a NAS, BorgBase, and a USB drive.
I've seen the mount point for the USB drives at both /media/marcs/BackInTime/Borg-DATA_X and am currently viewing the mount at /mnt/BackInTime4TB/BORG-DATA_X.
I can always navigate to the device where the repos are hosted through the file manager.
Usually when I come back on the computer after it's been asleep, I find a notification that "repo folder not mounted or moved". When I go into Vorta and check the profile and log, either the target repo is gone from the settings, or the source's is missing the list of folders to backup. Strangely, the exclusions are there.
I'm trying to pin down the issue, but I think it's something in the way my USB drives are mounted.
I'm not an expert at Linux, so it's a bit of a mystery to me.
Here's my etc/fstab file if it's of any help:
UUID=16b479c4-ce81-4504-acfe-54cb8886c3f4 / ext4 discard,noatime 1 1 UUID=60C7-F1A4 /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0 /swap/swap swap swap defaults 0 0 /dev/disk/by-id/wwn-0x50014ee267ff251d /mnt/BackInTime4TB auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=BackInTime4TB,x-gvfs-icon=BackInTime4TB 0 0 /dev/disk/by-uuid/d3fca3b7-bb6c-4eb0-becb-120074dd8a0a /mnt/DATA_3 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_3,x-gvfs-icon=DATA_3 0 0 /dev/disk/by-uuid/87208547-0160-4b7e-856f-d737a9b3396d /mnt/VirtualMachines auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=VirtualMachines 0 0 /dev/disk/by-uuid/4eef839e-c02d-4f3f-a0e2-1e1670cba46c /mnt/DATA_2 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_2,x-gvfs-icon=DATA_2,x-gvfs-symbolic-icon=DATA_2 0 0 /dev/disk/by-id/wwn-0x50014ee600bc8287 /mnt/Timeshift auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Timeshift,x-gvfs-icon=Timeshift,x-gvfs-symbolic-icon=Timeshift 0 0 /dev/disk/by-uuid/67edcebd-7dae-4444-9bdc-a9b73e50cc9b /mnt/DATA_1 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_1,x-gvfs-icon=DATA_1 0 0
defaults,user,noauto,nofail,_netdev, 0 0 192.168.68.61:/volume1/Backups /mnt/Asustor_Backup nfs defaults,user,nofail,_netdev, 0 0
Thanks for your time, I appreciate you getting back to me.
On Mon, Nov 4, 2024 at 3:13 PM Nicholas D Steeves @.***> wrote:
Hi @marcsitkin https://github.com/marcsitkin, Thanks for reaching out! The errors @m3nu https://github.com/m3nu notes may have emerged from Flatpack (not the Vorta flatpack itself).
Are you able to navigate to /media/marcs/BackInTime/BORG-DATA_1, as the marcs user, with your file browser? Are you able to access the README in that directory?
Repology.org indicates that Vorta 0.9.1 is available in "MX Linux MX-23 Testing", so maybe you could try that? MX community support channels should be able to help you enable that repository. It also has Borg 1.4.0 ("borgbackup" package).
— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta/issues/2107#issuecomment-2455612271, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN64KKRMN42GKHVVNB3ERXLZ67BMFAVCNFSM6AAAAABQIXOSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJVGYYTEMRXGE . You are receiving this because you were mentioned.Message ID: @.***>
-- Marc Sitkin 2024-Transatlantic Florida to Rotterdam Blog https://marcsitkin.smugmug.com/Transatlantic-Crossing-April-2023 2023-Transatlantic Florida to Barcelona Gallery https://marcsitkin.smugmug.com/Transatlantic-Crossing-April-2023 2024-Mexico Blog https://downmexicoway2024.blogspot.com/ 50 images from Iceland 2021 https://marcsitkin.smugmug.com/Iceland/Iceland-2021-50-Images/ Marc Sitkin Photography Web Site http://marcsitkin.smugmug.com
sten0
commented
1 week ago Hi Marc,
marcsitkin @.***> writes:
Hi- I'm currently using the flatpak version 0.91 from flathub. I back up to repo's on a NAS, BorgBase, and a USB drive.
Thanks for this info.
I've seen the mount point for the USB drives at both /media/marcs/BackInTime/Borg-DATA_X and am currently viewing the mount at /mnt/BackInTime4TB/BORG-DATA_X.
and "/media/marcs/BackInTime/Borg-DATA_X" is automatic (or takes a single click) using your desktop environment. "/mnt/BackInTime4TB/BORG-DATA_X" is the location configured in fstab. One possible cause for this issue is that Vorta can't guess which of these two locations will be used.
I can always navigate to the device where the repos are hosted through the file manager.
Thanks for confirming!
Usually when I come back on the computer after it's been asleep, I find a notification that "repo folder not mounted or moved". When I go into Vorta and check the profile and log, either the target repo is gone from the settings, or the source's is missing the list of folders to backup. Strangely, the exclusions are there.
Nice, you've identified a reproducer. Lets break this down into three tests.
Are you able to get your system into a state where some USB drives are mounted to /media/marcs, and others to /mnt/ ? This will probably require some trial and error involving suspending your computer when a drive is mounted, and then attaching a second one and then manually mounting it. Once you produce that state, can you use Vorta (installed from flatpak) to freely browse both locations? (either when adding backup sources or targets)
I'm trying to pin down the issue, but I think it's something in the way my USB drives are mounted.
Good hypothesis! Yes, this is the most important issue, and you may have found a bug with your desktop environment (XFCE?), and/or MX Linux.
There may additionally be a flatpak permission issue that compounds the bug.
Finally I've asked you to also look for a possible soft-fail issue.
I'm not an expert at Linux, so it's a bit of a mystery to me.
Here's my etc/fstab file if it's of any help:
Pluggable devices are handled by uDev, they are not in fstab
UUID=16b479c4-ce81-4504-acfe-54cb8886c3f4 / ext4 discard,noatime 1 1 UUID=60C7-F1A4 /boot/efi vfat noatime,dmask=0002,fmask=0113 0 0 /swap/swap swap swap defaults 0 0 /dev/disk/by-id/wwn-0x50014ee267ff251d /mnt/BackInTime4TB auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=BackInTime4TB,x-gvfs-icon=BackInTime4TB 0 0 /dev/disk/by-uuid/d3fca3b7-bb6c-4eb0-becb-120074dd8a0a /mnt/DATA_3 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_3,x-gvfs-icon=DATA_3 0 0 /dev/disk/by-uuid/87208547-0160-4b7e-856f-d737a9b3396d /mnt/VirtualMachines auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=VirtualMachines 0 0 /dev/disk/by-uuid/4eef839e-c02d-4f3f-a0e2-1e1670cba46c /mnt/DATA_2 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_2,x-gvfs-icon=DATA_2,x-gvfs-symbolic-icon=DATA_2 0 0 /dev/disk/by-id/wwn-0x50014ee600bc8287 /mnt/Timeshift auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=Timeshift,x-gvfs-icon=Timeshift,x-gvfs-symbolic-icon=Timeshift 0 0 /dev/disk/by-uuid/67edcebd-7dae-4444-9bdc-a9b73e50cc9b /mnt/DATA_1 auto nosuid,nodev,nofail,x-gvfs-show,x-gvfs-name=DATA_1,x-gvfs-icon=DATA_1 0 0
192.168.68.61:/volume1/Backups /mnt/Asustor_Backup nfs
defaults,user,noauto,nofail,_netdev, 0 0 192.168.68.61:/volume1/Backups /mnt/Asustor_Backup nfs defaults,user,nofail,_netdev, 0 0
This is pretty sophisticated. How did you create those "x-gvfs-show" lines? On a tangential note: You might be able to get 3× the speed out of this nfs mount with a bit of mount option tuning, and it would be worth adding to you "nice to have" TODOs.
Thanks for your time, I appreciate you getting back to me.
You're welcome :)
Regards, Nicholas
marcsitkin
commented
1 week ago Hi Nicholas-
I'll try to answer your questions as best I can.
I've been unable to get the USB drives mounted under /media they seem to be living at /mnt now. They are mounted at boot, and if unmounted and mounted again, reappear under /mnt
Do Vorta sources and targets resurrect when the drive reappears in the configured location? This tests the "soft fail" state. You can test it like this: I. Mount a drive, II. Configure it as a Vorta target, III. complete a successful backup, IV. Close vorta and unmount the drive, V. Open Vorta with the drive unmounted (the target repo will be gone), (Actually, if I click start backup, the Repo folder not mounted or gone appears.The repo still shows up in the repository field)VI. Close Vorta, VII. Mount the drive and restart Vorta, VIII: Does the configuration work now that the "soft failure" has been resolved? Yes
Are you able to get your system into a state where some USB drives are mounted to /media/marcs, and others to /mnt/ ? This will probably require some trial and error involving suspending your computer when a drive is mounted, and then attaching a second one and then manually mounting it. Once you produce that state, can you use Vorta (installed from flatpak) to freely browse both locations? (either when adding backup sources or targets) I cannot get them to switch mount points. If I plug in a different external drive, it appears under /media/marcs I repeated the resurrection tests with this removable USB drive, and it worked as expected. The /mnt usb drives were both added into /etc/fstab using the gnome disks utility. It may have been done in a previous distro, and I probably copy/pasted the entries into the /etc/fstab file of the current distro. The portable HD I just used for a test has no entries in /etc/fstab. I am working in the KDE Plasma 5.2x desktop.
192.168.68.61:/volume1/Backups /mnt/Asustor_Backup nfs
defaults,user,noauto,nofail,_netdev, 0 0 192.168.68.61:/volume1/Backups /mnt/Asustor_Backup nfs defaults,user,nofail,_netdev, 0 0
This is pretty sophisticated. How did you create those "x-gvfs-show" lines? (They must be created automatically by Gnome Disks)On a tangential note: You might be able to get 3× the speed out of this nfs mount with a bit of mount option tuning, and it would be worth adding to you "nice to have" TODOs. This entry was made manually by following a published guide to nfs
I've had a couple occasions where my primary (/root) disk partition has thrown an "out of space " error while running backups with Vorta. I've cleared out quite a bit of disk space over the weekend to see if that might be part of the issue. My Vorta cache is quite huge at 12.6 GB, and my drive relatively small by today's standards. I'm running a 512GB ssd at 92% full. I'm on the cusp of building a new machine, and have been trying to avoid changing media at this stage. Is this out of space issue perhaps corrupting my setting files?
Finally, Flatpak permissions: Everything is at the default settings with the exception of "All user files", which is togelled to "on" to allow access.
Best,
sten0
commented
1 week ago Hi Marc,
Thank you for the additional information; reply follows in-line:
I've been unable to get the USB drives mounted under /media they seem to be living at /mnt now. They are mounted at boot, and if unmounted and mounted again, reappear under /mnt …
Does the configuration work now that the ßoft failure" has been resolved? Yes … I cannot get them to switch mount points. If I plug in a different external drive, it appears under /media/marcs I repeated the resurrection tests with this removable USB drive, and it worked as expected.
So you're not able to reproduce the disappearing sources issue anymore?
The /mnt usb drives were both added into /etc/fstab using the gnome disks utility. It may have been done in a previous distro, and I probably copy/pasted the entries into the /etc/fstab file of the current distro. The portable HD I just used for a test has no entries in /etc/fstab. I am working in the KDE Plasma 5.2x desktop.
Is the primary use of these fstab entries to give your external drives human-friendly persistent names? If so, you might prefer switching away from x-gvfs-stuff to use filesystem or partition labels instead. Last I compared the these, labels were much more reliable, but maybe that's changed by now? Labels are persistent and will follow the drive from system to system, which is how I think most people expect drive names to function. If you do this, please be careful where you get your information, and consider experimenting on a USB flash drive with unimportant data, because you need to use a nondestructive method!
Your original bug report includes the following log entry:
PermissionError: [Errno 13] Permission denied: '/media/marcs/BackInTime/BORG-DATA_1'which appears to be a problem with the target rather than source. Is this reproducible?
I've had a couple occasions where my primary (/root) disk partition has thrown an öut of space " error while running backups with Vorta. I've cleared out quite a bit of disk space over the weekend to see if that might be part of the issue. My Vorta cache is quite huge at 12.6 GB, and my drive relatively small by today's standards. I'm running a 512GB ssd at 92% full. I'm on the cusp of building a new machine, and have been trying to avoid changing media at this stage. Is this out of space issue perhaps corrupting my setting files?
To be honest, I don't know if ~/.local/share/Vorta/settings.db is vulnerable to out-of-space conditions (ENOSPC), nor what steps Vorta takes to mitigate this. Maybe @m3nu knows?
That's something you can test though, like this:
# Make sure Vorta isn't running
cp ~/.local/share/Vorta/settings.db ~/vorta_pre-backup_settings.db
# Start Vorta and reproduce the failed backup
cp ~/.local/share/Vorta/settings.db ~/vorta_post-backup_settings.dbthen use sqlitebrowser to manually search for missing sources or
targets in ~/vorta_post-backup_settings.db
That said, I recommend that you use an application like Filelight (KDE) or "Disk Usage Analyzer"/Baobab (GNOME) to identify why you have so little free space.
Cheers, Nicholas
marcsitkin
commented
1 week ago Comments below, thanks. Since doing a major cleanout of my home directory and getting to 45GB free, Vorta has been running backups to local, remote and the NAS repos without error. I'm beginning to think the problem was related to running out of disk space. I'm going to keep on eye on things this week before making any changes to fstab, as I've not had problems with these mounts over the years otherwise.
On Wed, Nov 13, 2024 at 9:39 AM Nicholas D Steeves @.***> wrote:
Hi Marc,
Thank you for the additional information; reply follows in-line:
I've been unable to get the USB drives mounted under /media they seem to be living at /mnt now. They are mounted at boot, and if unmounted and mounted again, reappear under /mnt …
Does the configuration work now that the ßoft failure" has been resolved? Yes … I cannot get them to switch mount points. If I plug in a different external drive, it appears under /media/marcs I repeated the resurrection tests with this removable USB drive, and it worked as expected.
So you're not able to reproduce the disappearing sources issue anymore?
Correct, so far this week, sources seem to be kept correctly
The /mnt usb drives were both added into /etc/fstab using the gnome disks utility. It may have been done in a previous distro, and I probably copy/pasted the entries into the /etc/fstab file of the current distro. The portable HD I just used for a test has no entries in /etc/fstab. I am working in the KDE Plasma 5.2x desktop.
Is the primary use of these fstab entries to give your external drives human-friendly persistent names? If so, you might prefer switching away from x-gvfs-stuff to use filesystem or partition labels instead. Last I compared the these, labels were much more reliable, but maybe that's changed by now? Labels are persistent and will follow the drive from system to system, which is how I think most people expect drive names to function. If you do this, please be careful where you get your information, and consider experimenting on a USB flash drive with unimportant data, because you need to use a nondestructive method!
The labels seem to be persistent. If I boot off a USB stick into say Fedora 40, the drives are mounted with the same names as under the MX23 system, so they are functioning as expected.
Your original bug report includes the following log entry:
PermissionError: [Errno 13] Permission denied: '/media/marcs/BackInTime/BORG-DATA_1'which appears to be a problem with the target rather than source. Is this reproducible?
No, because the mounts for that drive are under /mnt. I haven't gotten them to mount under /media again.
I've had a couple occasions where my primary (/root) disk partition has thrown an öut of space " error while running backups with Vorta. I've cleared out quite a bit of disk space over the weekend to see if that might be part of the issue. My Vorta cache is quite huge at 12.6 GB, and my drive relatively small by today's standards. I'm running a 512GB ssd at 92% full. I'm on the cusp of building a new machine, and have been trying to avoid changing media at this stage. Is this out of space issue perhaps corrupting my setting files?
To be honest, I don't know if ~/.local/share/Vorta/settings.db is vulnerable to out-of-space conditions (ENOSPC), nor what steps Vorta takes to mitigate this. Maybe @m3nu knows?
That's something you can test though, like this:
# Make sure Vorta isn't running cp ~/.local/share/Vorta/settings.db ~/vorta_pre-backup_settings.db # Start Vorta and reproduce the failed backup cp ~/.local/share/Vorta/settings.db ~/vorta_post-backup_settings.dbthen use
sqlitebrowserto manually search for missing sources or targets in~/vorta_post-backup_settings.dbThat said, I recommend that you use an application like Filelight (KDE) or "Disk Usage Analyzer"/Baobab (GNOME) to identify why you have so little free space.
I've utilized filelight to analyze the disk usage of my /root device, and have had to move my Google Drive sync folder and all my Music off the drive to other locations, freeing up about 30GB+. I now have about 10% free space, which seems to be enough that Vorta is running without causing an out of space error. Using filelight, I can see that the Vorta/Borg cache is at about 12.6GB. It seems to be stable at this number. Not sure if there's any way to clear some of this out. I've read some of the FAQ info on replacing the cache folder with a file, but not sure that's the best solution for me. I'm keeping my fingers crossed that having cleared up space, I'll be ok until I can get the new machine built and configured.
Best,
Cheers, Nicholas
— Reply to this email directly, view it on GitHub https://github.com/borgbase/vorta/issues/2107#issuecomment-2473808338, or unsubscribe https://github.com/notifications/unsubscribe-auth/AN64KKVXPW265MI7YLXRSL32ANQBZAVCNFSM6AAAAABQIXOSHOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINZTHAYDQMZTHA . You are receiving this because you were mentioned.Message ID: @.***>
-- Marc Sitkin 2024-Transatlantic Florida to Rotterdam Blog https://marcsitkin.smugmug.com/Transatlantic-Crossing-April-2023 2023-Transatlantic Florida to Barcelona Gallery https://marcsitkin.smugmug.com/Transatlantic-Crossing-April-2023 2024-Mexico Blog https://downmexicoway2024.blogspot.com/ 50 images from Iceland 2021 https://marcsitkin.smugmug.com/Iceland/Iceland-2021-50-Images/ Marc Sitkin Photography Web Site http://marcsitkin.smugmug.com
Description
On scheduled run, system message received: Repo folder not mounted or moved. Checking in the Vorta Application, all repository locations indicate : No repository selected. Adding an existing repository gives message: Unable to add y9our repository. No log entry. Checking each profile shows several local missing repositories, one with wrong repository, 2 with correct repositories. Borg Base repositories include 1 with no repository, 1 with a repository, local disk backups ( mounted below /media) show 2 repositories missing, 2 connected. 2 profiles to back up to NAS (mounted under /mnt) indicate 1 repository missing, 1 present.
Vorta profiles were set up 4 years ago, and this happened starting about 2 weeks ago.
Reproduction
OS
MX Linux23.4, CPU: 6-core Intel Core i7-8700 (-MT MCP-) speed/min/max: 1400/800/3201 MHz Kernel: 6.10.12-1-liquorix-amd64 x86_64 . KDE PLasma v 5.275
Version of Vorta
Vorta Version 0.9.1,
What did you install Vorta with?
Flatpak
Version of Borg
Borg Version 1.4.0
Logs