GoChris

Delete the venv folder in the appdata for it and then it will work.

Getting this error on the discordbot now. Probably after a docker update? Not sure, I backup/restart everynight. "Error: Command '['/data/venv/bin/python', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1." Solution? I did delete and re-create the container (kept appdata)

Also this too, that can happen.

Perhaps in your setup sure, but I don't consider it a misconfiguration. I have large files that when created or downloaded need/benefit from my speedy cache device. But if files are copied to the share from other devices on the network, there is no reason to use the cache device (as they are quite large) so prefer them to go straight to the array. These files are created on the cache, then they get moved to the share folder, which, won't move them to the array the way it works, and then the mover also won't pick them up. I could exploit the bug (IMO) that the min free space required for a share also applies to the cache device as well, and set that value to be larger than the cache size (that only works while you have large enough free space on some data drives).

From a cache device to the array.

Sorry if this has been asked/mentioned. Can there be an option to move files for a share for which the setting "Use cache pool" is set to no?

It worked in private browser, firefox, disabled all extensions, didn't fix it, but clearing cookies and site data and now it works again.

Ya I have this problem too.

Further to the questions above about LibreNMS not auto discovering or polling. If you load up a console and run: ./discovery.php -h <device ip> It will do the discovery. Not sure why this is not done when adding, and you can also manually a poller, but, that should be done on a cron or something. I think this docker isn't correct. ./poller.php -h <device ip>

Have you managed to get this docker working? My vm crashed that housed my LibreNMS, so I switched to this docker, and I am getting the same issue. I can add the device, but it does not discover anything.

Server...hung, local input was working, network was unavailable. This was on the screen. Attached the latest diagnosis, for now I'm paused the rebuild/sync in order to grab some files off, as I'm not sure my backups have been working the past few weeks (time to build a backup pc). tower-diagnostics-20210614-2002.zip

Sorry for the late reply, server wasn't stable with the 2nd HBA card in it for some reason so back to 1 and a vid card. I believe it was disk 2 or 3 that was giving the errors, which is showing fine now. Just started the array and it is showing disk 16 and 7 as unmountable. tower-diagnostics-20210614-1758.zip

Sorry, forgot to add, edited and added.

Ok, so I recently added back a 2nd hba card. A drive went missing (timed out). So I was rebuilding that, during that one other drive dropped out, then a bit later one drive was just showing errors during the rebuild. I swapped out that HBA for a 3rd, maybe it was no good. Anyway, during all this I'm pretty certain nothing was written to the array at all. So, I want to assume parity is fine I guess, because I can't imagine all the read errors on the 3rd "failed" drive would mean good data on the actual rebuilding. I do have two parity drives. What steps do I take, to assume parity is valid, restart the build on the drive that I had started on, and assume the other 2 drives are fine also? Here is how it's looking, disk 16 was in the middle (well, not even close to the middle at all actually) of the rebuild when the other issues popped up. Thanks for any help you can provide, you can also hit me up on discord in the official. Edit: Or, if I assume the HBA swap fixes the drive (2 or 3, whichever) errors, I could just rebuild 16 again and hope it works? tower-diagnostics-20210614-0803.zip

Yes, rebooted and the shares are back. Log did get full afterwards yes and good now also after the reboot. Thanks. Will rebuild that drive again, still checks out fine.

Tried to watch a show, nothing was playing, went to check to make sure I could access files on the share, got an error accessing the share. Checked via a terminal and got "cannot access '/mnt/user': Transport endpoint is not connected" error accessing anything in /mnt/user. So, got weirded out, started and stopped the array, then the shares list was gone (empty), and on array start a drive is disabled (I'm guessing there's nothing wrong with it, probably a timeout on start? Will worry about that after a reboot). Also I then setup a root password (finally) cause I got paranoid with oddities, never know what's in those linux isos sometimes. So to sum up, my shares are missing after I started and stopped the array to the due transport endpoint is not connected problem. I have not done a reboot yet (finishing up a preclear). Any insights or anything I should check or do before I reboot? I assume on reboot I'll have to rebuild that disabled disk not a huge deal. tower-diagnostics-20210612-2144.zip

Correct. I will update my original post to be more clear, I guess I wasn't as clear as I thought.

Yes but the share min free space takes precedence when that share is set to use the cache, which is ultimately the problem.

The alternative would be to have a separate setting for how much free space you want to maintain on the cache, just like you can for a share. Cache drives are not going to be as big as data drives (let's assume we're talking about 99% of setups), so chances are you might fill it up more than a share setting, but there can remain more than enough space for file transfers. If you need/want an example, I might have my share set to 150GB min, but various files could have been written to multiple shares and reduced the cache drive to (just) under 150GB. If I then want to write another file (size is irrelevant as long as it's under the free space size), it would skip the cache and go to the share directly, obviously that's slower, but really no reason it couldn't go to the cache (before the mover catches up).

If a share is not set to cache only, and a min free space is set, I think it should only apply to free space on HDDs, not how much free space is on the cache. I only want to fill up my drives to certain amount, but I always want to utilize the faster write speed of using the cache drive, however if the cache fills up and has less free space than the share setting, it will write straight to an HDD and be much slower. Making it an option would work too. Perhaps a better explanation:

You have to edit the config file in appdata for the settings you want to stay between sessions.

I love dockers, and I've love to see unraid -> unraid backup/sync.

You have to edit the values in the rtorrent.rc file in your appdata/rutorrent/rtorrent folder

If we don't win a badge, hope we can buy one.

Happy Birthday! I can't even remember how long I've used it, close to 10 years maybe? I just love that it's so easy to expand storage and fix failures, I'm never really that worried about catastrophic failures. Dockers are so easy, it's really quite great. The plugins and community are icing on the cake.