• Content Count

  • Joined

  • Last visited

Everything posted by sonofdbn

  1. Just saw this post. No problems with the RM650x. In fact, I got another one for my then new PC build and one for my daughter's PC a few years ago, and all three run fine. (Also meant that I got to use the unused cables for my unRAID server 😉.)
  2. I'm getting lots of entries in the access.log file: nnn.nnn.n.nnn - admin [02/May/2021:23:24:56 +0800] "POST /plugins/httprpc/action.php HTTP/1.1" 200 892 "http://nnn.nnn.n.nn:9080/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36" nnn.nnn.n.nnn - admin [02/May/2021:23:24:56 +0800] "POST /plugins/httprpc/action.php HTTP/1.1" 200 55 "http://nnn.nnn.n.nn:9080/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.93 Safari/537.36" nnn.nnn.n.nnn - admin [02/May/2021:23:24:5
  3. Thanks for pointing out how port-forwarding will be done by PIA in future. I too will be in the same boat - and looking for suggestions for an alternative VPN.
  4. Thanks for the quick replies. OK, I might just change the SSD - or is there a chance it's a SATA cable problem?
  5. Darn. Does this mean I should run memtest? I have ECC RAM, and I've come across a post (by!) that says memtest doesn't really help. I have a Supermicro X10SDV-TLN4F, which has IPMI.
  6. So in the end I changed the BTRFS cache pool to a single SSD (also BTRFS), re-created everything and was fine for a few months. Unfortunately today I got error messages from the Fix Common Problems plug-in: A) unable to write to cache and B) unable to write to Docker Image. I'm assuming that B is a consequence of A, but anyway I've attached diagnostics. Looking at the GUI, Docker is 34% full and the 1 TB cache drive, a SanDisk SSD, has about 20% free space. But looking at the log for the cache drive, I get a large repeating list of entries like this: Jul 6 18:36:57
  7. My APC UPS died a while ago and I'm only now getting round to replacing it. Probably it's just the battery, but there's not much information available from APC. I used to have my unRAID box, a Synology 4-bay box and my Win 10 PC running off it. In truth, it might have been too much for the APC (650VA, 390W). But since I have to replace something anyway, I was wondering whether it's better to have one UPS per device or one big(ger) UPS. I only need the UPS to enable a clean shutdown; our power doesn't go out often, but a few times a year it goes out when there's lightning. I'm think
  8. Came across this issue in reddit, and after doing a bit of reading in this thread and elsewhere on the forum I'm quite concerned. BUT I don't know how to check how badly - if at all - I'm affected. So far what I've done is installed iotop and libffi from the Nerd Tools plug-in and I've run iotop -oa, but I don't know how to interpret the results. loop2 does seem to be writing more than anything else, but how do I know which disk it's writing to? Does it write only to the cache disk? Could someone help out by posting what commands a casual user could try to see what's ha
  9. The UD is 500GB, and it's likely to be too small, especially taking into account other stuff I want to put on it.
  10. Yes, it's a downloads share for torrents. I did try using cache-prefer, but then of course some files did, correctly, go to the array. But I didn't like keeping the array disk spinning for reads. What I'd like to do is download to my unassigned device (SSD) and then manually move things I want to seed longer back to the cache drive. But I can't find any way of doing this in the docker I use (rtorrentvpn).
  11. I'm trying to look at what's going wrong on my server, and previously enabled the local syslog server, writing to my cache disk as outlined here: (It's in the FAQ for unRAID v6 topic.) The problem is that my cache drive might be part of the problem, so I'd like to avoid writing to it. Is there a way of writing the local syslog folder to an unassigned device? I have an unassigned SSD which I could use. When I try to select a local syslog folder through the GUI, I only get a choice of sh
  12. Now looking at Fix Problems, I see errors: Unable to write to cache (Drive mounted read-only or completely full.) and Unable to write to Docker Image (Docker Image either full or corrupted.). According to Dashboard, doesn't look like cache is full (90% utilisation - about 100 GB fee). This is what I get (now) when I click Container Size on the Docker page in the GUI. Name Container Writable Log --------------------------------------------------------------------- calibre 1.48 GB 366 MB 64.4
  13. Took a quick look at the logs in the above diagnostics and they seem to have omitted docker.log.1. So I've attached it here after editing out many similar lines. (Think file size was too big to upload.) Plex container ID is 8138acb243f3 Pihole container ID is 358107cb7f64 These two seem to come up in the logs. docker.log.1.txt
  14. I've re-created the docker image and all seemed fine. But this morning the log usage on the Dashboard jumped from 1% to 30% when I refreshed the browser. I did reinstall Plex yesterday, and prior to that the log was at 1% of memory (I have 31.4 GiB of usable RAM). Unfortunately it seems that the Dashboard doesn't necessarily update the log until you refresh the browser, so it's possible that the log size was higher than 1% earlier. Is Log size on the Dashboard just the syslog or also docker log? Because docker log is at 36MB, syslog at only around 1MB. Diagnostics are a
  15. Can't say I did check the settings. But I'm sure the docker image wasn't anywhere near full when I looked at the dashboard. I remember thinking that there was significantly more free space since I'd left out a number of dockers when I did the reinstall.
  16. OK, I can do that, but I already re-created the docker image when I reinstalled the dockers on the re-formatted cache drive. Any way of reducing the chance of this corruption happening again? Or could it be that there's some problem with the appdata files that I backed up and used to reinstall the dockers that is causing this?
  17. Sorry to be back again, but more problems. So I backed up what I could, then reformatted the cache drives and setup the same cache pool, then reinstalled most of the dockers and VMs. It was a pleasant surprise to find that just about everything that had been recovered was fine, including the VMs. As far as I could tell, nothing major was missing. Anyway, the server trundled along fine for a few days, then today the torrenting seemed a bit slow, so I looked at the dashboard and found that the log was at 100%. So I stopped my sole running VM and then tried to stop some do
  18. Command seems to be OK. Am now happily copying files off /x to the array. I swear that some files that couldn't be copied before are now copying across at a reasonable - even very good - speed. A few folders seem to be missing entirely but everything I've tried so far has copied across with no problem. I'm hopeful that most of the files will be recovered. Thanks again for all the help.
  19. Thanks for all the help so far. Given that my cache pool had two drives, sdd and sdb, is this the correct command to mount them? mount -o usebackuproot /dev/sdd1 /x
  20. I changed a SATA cable on one of the cache drives in case that was a source of the weird online/offline access. Then I started the array with cache drives unassigned, and mounted the cache drives again at /x. Ran btrfs dev stats /x and got 0 errors (two drives in the pool): [/dev/sdd1].write_io_errs 0 [/dev/sdd1].read_io_errs 0 [/dev/sdd1].flush_io_errs 0 [/dev/sdd1].corruption_errs 0 [/dev/sdd1].generation_errs 0 [/dev/sdb1].write_io_errs 0 [/dev/sdb1].read_io_errs 0 [/dev/sdb1].flush_io_errs 0 [/dev/sdb1].corruption_errs 0 [/dev/sdb1].generation_errs 0
  21. In trying to do the btrfs restore, I realised that it might not be surprising that "1) Mount filesystem read only (non-destructive) " above didn't work, because the disk is already mounted. I haven't had a problem actually accessing the disk. And it's then not surprising to see the last error message above. So my problem was how to unmount the cache drives to try 1) again. Not sure if this is the best way, but I simply stopped the array and then tried 1) again. Now I have access to the cache drive at my /x mountpoint, at least in the console. But I was a bit stuck trying to use it
  22. OK, so the "buffer" is actually used. I swear that at one time I knew all of this 🙂
  23. Thanks, that's useful information. Got to re-think my setup when I eventually sort out the cache disk.
  24. I guess what I'm saying is what's the use case for a Cache Minimum Free setting? If there's no temporary use of the minimum free space, isn't it just reducing the size of your cache?
  25. I don't use mover at all (so not really using cache disk as a cache). I move files manually. But the cache-prefer share idea is excellent. I only "discovered" cache preferences a short time ago and didn't have a good idea of how they could be used. I didn't even know there was a Cache Minimum Free setting - but what happens when you hit the minimum free (ignoring for this discussion any cache-prefer shares)? Does this trigger a warning (and continue writing into the "buffer") or does it just act like a hard limit to the cache drive size?