No, I ended up reinstalling at some point and the issue has not returned.
Posts by niemer
-
-
Bummer, I was hoping to avoid that.
-
I can't umount because the target is busy.
-
It's currently mounted, so I'm guessing that's why it's not empty.
-
I get the same mountpoint error.
-
I've added a drive to a MergerFS pool and the message that pops up is NOTE:The changes won't take effect until you've restarted the system or manually remounted the filesystem. How do I do a manual remount? I tried /srv/fb803389-0bb8-46c5-92c6-e96a213e4c77 -o remount but I get the following message
fuse: mountpoint is not empty
fuse: if you are sure this is safe, use the 'nonempty' mount option
Is it safe to use the 'nonempty' option in this case?
-
Version 5.1 of the borgbackup plugin is in the repo. This allows you to skip the borg init command to use an existing repo. If you check the skip init checkbox, it will run borg check --repository-only --info using the information supplied. If it is wrong, the check command will fail and you will be allowed to edit the info..
That worked, thanks!
-
Whatever is happening seems to be happening at, or around, 00:00 every day. The timestamps show that the server was up for ~17 hours 40 min before this happened which correlates to the spike in processes just after midnight in the graph below. But, as you can see, the system otherwise looks healthy.
-
This issue was not present over the last year with OMV4
-
I'm having a recurring issue with OMV5 where my SMB shares stop working after some time and I have to reboot OMV to get them to work again. I'm still able to access the web interface and everything looks and functions OK there, low memory and cpu use is reported. Stopping the SMB daemon times out on reboot when this occurs and the drives fail to cleanly unmount.
I have 3 machines connected to these shares, one Win10, and two Debain Buster servers, I have noticed the average load of the Debian servers goes through the roof when they loose access.
When this happens there is some kernel output on the console that might point someone more knowledgeable in the right direction to give me some help.
I've also noticed that I'm getting stale file handles on some of my client mounts, and this is what I'm seeing on reboot of one of them, the server was up when this was rebooted. Oddly, the share in the last line was not one of the ones with a stale file handle.
-
Isn't the key (keyfile?) for encryption? Either way, the plugin doesn't store any directories for keys. I just assume the borg binary "knows" where to find those based on the path passed?
Yes, I think your assumption is correct.
-
Take a look at the remote filesystems under tips and tricks here
-
And encryption mode = Auto.
This also worked for me.
-
Read this about how to use 2FA and App Passwords
https://openmediavault.readthe…/notifications.html#gmail
And you need to use port 465, not 587
-
I think an import button is the best way to go. Since any action to get info about a repo will require a passphrase if one is enabled, the user will have to know to supply it. I will see what I can come up with.
It's not just a passphrase, but a passphrase and a key. When borg asks for those it automatically creates the directory for the key(s) and tells the user where it's located, those key(s) need to somehow end up in that directory.
-
I already guessed that. I need command line workflows to translate into how the plugin works.
There's nothing extra needed using the command line to access an existing repo, I think all the plugin would need is the location of it to work. like Henfri said, there needs to be an option to use existing as well as create new.
Quote from ryecoaaronOne of the main concepts of OMV is using shared folders. None of the plugins are written with using the command line in mind. That said, shared folders are translated into absolute paths. All I can guess is you are still using the /sharedfolders bind mount that is now disabled by default.
The original repos were created in OMV4, so going forward into OMV5 this may not be an issue any longer.
-
I guess my first suggestion would be add the ability to import existing repos.
Secondly, it would be best if the plugin used absolute paths rather than creating a shared folder for the repos. If any operations are done via the command line using the absolute path to the repo, rather than the shared folder path, the path in where borg looks for the repo is updated and the plugin doesn't know how to handle it.
-
Many, and never got any errors about them missing...
-
Individual disks. The content file is only present in one, but specified to be in all thee with the SnapRAID plugin.
-
Anyone? How is it supposed to work? Is what I'm experiencing expected behavior?