vacuu
Members
-
Joined
-
Last visited
Everything posted by vacuu
-
Its working now. It was my bad, I assumed I had to change the Network Type to custom, but that doesn't work. That being said: When configuring unraid, Bambuddy needs a routing of the privileged port 990 as described in the guide: iptables -t nat -A PREROUTING -p tcp --dport 990 -j REDIRECT --to-port 9990 iptables -t nat -A OUTPUT -o lo -p tcp --dport 990 -j REDIRECT --to-port 9990 To make it consistend even after rebooting the unraid server, these two lines have to be added to /boot/config/go As this privileged port 990 seems to be reserved (and used in bambuddy) for FTPS, I assume that messes with any FTPS services in unraid as it now routes every incoming and outgoing traffic away from these ports to ports that bambuddy can use. I don't use FTPS in unraid, but that might be something some want to consider or at least keep in mind when setting up bambuddy. Im still trying to get everything working, but atleast this issue is solved for now.
-
Was anyone successfull in adding and using the virtual printer feature? I was able to setup everything according to https://wiki.bambuddy.cool/features/virtual-printer/ and it indeed connects and everything. But when I try to send the print to this virtual printer, I get a "connection failed" error. I suspect some port issue, but didnt figure out yet what to do?
-
I think I found the issue here. In your first post you mention the following: I guess that's why by default the "Borg Repo (Backup Destination):" is set to "/mnt/disks/borg_backup/cache/" in the blueprint, which I did not change. But if the "unassigned devices plugin" isn't activated, this path does not lead to a device, therefore the system uses the root path (?). As I don't have other devices attached (and no real way to do this), I don't have this plugin activated. When checking the settings I always assumed that "/mnt/disks/" just is a path to write to one of the disks in the array without specifying one. Which its not. And that is kinda confusing to me. This setup worked okay for 1,5 years and 5TB of files, but at some point the cache filled the root path up until there was no space left and thats why unraid started acting so weird. I changed the path to the cache drive and I'm running a prune command right now. We will see how that turns out, but I'm pretty confident that this was the issue. So far, it looks much better.
-
I don't really know where to start as I think there are happening a few things that shoudn't happen in a few layers. I set up unraid 1,5 years ago and installed borgmatic for remote backups to hetzner. Borgmatic and unraid worked fine for over a year. All of a sudden, it stopped. With some investigation, I found the following in the logs: I checked every "space" I could imagine. I upgraded the hetzner remote space, I double checked everything locally but all seemed fine with enough space left on the array and cache. Concerning to me: at the same time, the whole unraid started to act weird. GUI was unresponsive, I got weird, cryptic error messages from time to time, other docker containers stopped repsonding etc etc. After fiddeling around, I upgraded my RAM form 12 GB to 16 GB and everything worked great again. So I guess the "device" with no space left was my system memory? Alright, fine. Everything went back to normal. But sure enough, after a few weeks with more stuff to backup (and I assume a bigger database which is written into memory at every borg action?), it broke again. But now I can't just extend my RAM as I maxed out what my system can handle. Whats weird to me: after a fresh restart of unraid, everything is working great. When I start a backup or prune, the RAM usage of docker goes up to 65%, borg fails, I stop the whole container and instead of (most of) the 65% just beeing freed again, this amount just stays allocated but instead of beeing part of "docker" usage, it turns into "system" usage. A quick look at TOP I can't find any process allocating that much memory. This is the top line of top with all processes allocating <2.5% memory: And the worst of all: unraid starts acting weird again. In the Main Tab the devices disappear and appear again, repeating once a second. Temperature values are just "*", Boot device is an empty listing. Connecting to shares by SMB isn't possible anymore and the list goes on and on. Only a restart brings everything back to normal (until the next borg run). At times the system was so irresponsive, that I had to shut it down by pulling the plug as there was no way to initiate a reboot in the GUI. This doesn't happen immidiatly/every time, that's why I just refere to unraid acting "weird" So my issue consists of two parts: 1. How do I get borg(matic) working again without the prossibility to upgrade the memory again? (Which might not be solved here - fair) 2. Any issue of a container in docker shouldn't affect the system in that way, should it? I seems to me, whatever goes wrong, should be handled more gracefully by the system. Just because a container goes rogue (espacially as "not enough RAM" is a predicatable error?), It shouldn't drag the whole system down? (I know how docker is not a VM and more tied to the system by using the same processes... but still?) I already asked for help in the borgmatic support thread, but the maintainer asked me to move it here as he agrees that there must be broader issue here. As I said, I don't really know where to start. Any help would be appreciated. Where should I start? What info is necessary? Attached you'll find some documentation "*_before*" and *"_after*". Between these all I did was to start a "borgmatic prune" command in the console of the borgmatic container and waited for the error to happen (plus tried to connect via smb so this issue is documented as well). When I tried to generate a diagnostic.zip afterwards, hell broke loose again. The whole GUI disappears (blank page), refresh (after pressing many times ctrl+r!) brings it back up only for it to disappear right away. Sometimes it works for a few seconds, then I can try to give the command to shut something down. Sometimes not. The .zip file never was downloaded which is why I can't attach it. Going back to the tab to try it again is impossible. All I have is a copy of the log which is shown while the .zip is being created, also find attached. FYI: This is not an issue with 7.0.0 alone, this issue drives me crazy for like 3 months now. Thanks a lot!
-
No snapshots used and 4,5TB free space
-
I don't really know where to start as I think there are happening a few things that shoudn't happen in a few layers. But as borgmatic in unraid is the first layer, Ill start here. Borgmatic worked fine for over a year. All of a sudden, it stopped. With some investigation, I found the following in the logs: I checked every "space" I could imagine. I upgraded the hetzner remote space, I double checked but everything locally and all seemed fine. Concerning to me: at the same time, the whole unraid started to act weird. GUI was unresponsive, I got weird, cryptic error messages from time to time, other docker containers stopped repsonding etc etc. After fiddeling around, I upgraded my RAM form 12 GB to 16 GB and everything worked great again. So I guess the "device" with no space left was my RAM? Alright, fine. Everything went back to normal. But sure enough, after a few weeks with more stuff to backup, it broke again. But now I can't just extend my RAM as I maxed out what my system can handle. Whats weird to me: after a fresh restart of unraid, everything is working great. When I start a backup or prune the RAM usage of docker goes up to 55%, borg fails, I stop the whole container and instead of the 55% just beeing freed again, this amount just stays allocated but instead of beeing part of "docker" usage, it turns into "system" usage. A quick look at TOP I can't find any process allocating that much memory. This is the top line of top with all processes allocating <2.5% memory: And the worst of all: unraid starts acting weird again. In the Main Tab the Devices disappear and apear again once a second. Temp value is just "*", Boot device is an empty listing. Connecting to shares by SMB isn't possible anymore and the list goes on and on. Only a restart brings everything back to normal (until the next borg run). So my issue consists of two parts: 1. How do I get borgmatic working again without the prossibility to upgrade the memory again? 2. Any issue of a container in docker shouldn't affact the system in that way, should it? I seems to me, whatever goes wrong, should be handled more gracefully by the system. Just because a container goes rogue (espacially as "not enough RAM" is a predicatable error), It shouldn't drag the whole system down? (I know how docker is not a VM and more tied to the system by using the same processes... but still?) As I said, I don't really know where to start. Any help would be appreciated. Where should I start? What info is necessary? Thanks a lot!
-
I just installed paperless-ngx as described in https://flemmingss.com/how-to-set-up-paperless-ngx-on-unraid/ The 'media', 'consumption' and 'export' are mounted into the share "Documents". The share is set to "public" access and the folders show up. Unfortunately, the folders are read only. The "Documents" root is correctly read/write. "Access Mode" for all folders in the settings is set to 'read/write'. Does anyone have an idea what I might have done wrong? Update: I found the solution. The folders 'media', 'consumption', 'export' should exist in the share before the docker app starts. If the app generates the folders on startup, they seem to have the wrong owner or something similar. Now everything works great!
