• Posts

  • Joined

  • Last visited

Everything posted by rockard

  1. Regarding Luckybackup, I have had the same experience as Kris6673 in that it only randomly seems to run on schedule. Last time it ran on schedule (every day at 8:50) was two days straight on April 16 and April 17, and since then it hasn't run. Now when I went into the GUI I see the schedule, but when I click view current crontab it says "/luckybackup - no crontab entries exist". So I click cronIT and it says "Your crontab is updated successfully", but when I click view current crontab it still says it's missing. So I check the log, and I see this: ---Checking if UID: 99 matches user--- ---Checking if GID: 100 matches user--- ---Setting umask to 0000--- ---Checking for optional scripts--- ---No optional script found, continuing--- ---Checking configuration for noVNC--- Nothing to do, noVNC resizing set to default Nothing to do, noVNC qaulity set to default Nothing to do, noVNC compression set to default ---Starting...--- ---Starting cron--- ---Version Check--- ---luckyBackup v0.5.0 up-to-date--- ---Preparing Server--- ---ssh_host_rsa_key keys found!--- ---ssh_host_ecdsa_key found!--- ---ssh_host_ed25519_key found!--- ---Starting ssh daemon--- ---Resolution check--- ---Checking for old logfiles--- chown: changing ownership of '/luckybackup/.config/crontabs/crontabs': Operation not permitted chown: changing ownership of '/luckybackup/.config/crontabs/luckybackup': Operation not permitted chmod: cannot access '/luckybackup/.config/crontabs/luckybackup': Permission denied ---Starting TurboVNC server--- ---Starting Fluxbox--- ---Starting noVNC server--- WebSocket server settings: - Listen on :8080 - Flash security policy server - Web server. Web root: /usr/share/novnc - No SSL/TLS support (no cert file) - Backgrounding (daemon) ---Starting ssh daemon--- ---Starting luckyBackup--- The "Operation not permitted" looks very suspicious to me Is that a problem only on my container, and if so any ideas how to fix it?
  2. The VNC log file from the container has errors, attached an excerpt from it vnc.log
  3. Both Chrome and Edge (fired up for the first time ever to test this) give the same behaviour, and opening a page in incognito in Chrome should not use any cached resources. EDIT: Thanks for a fast reply! EDIT2: Did the delete site from history in Chrome anyway, but no difference EDIT3: Here's the output of ps from the console: # ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 09:12 ? 00:00:00 /bin/bash /opt/scripts/ root 15 1 0 09:12 ? 00:00:00 cron -- p root 16 1 0 09:12 ? 00:00:00 su luckybackup -c /opt/scripts/ luckyba+ 17 16 0 09:12 ? 00:00:00 /bin/bash /opt/scripts/ luckyba+ 46 1 0 09:12 ? 00:00:00 SCREEN -S Xvfb -L -Logfile /luckybackup/XvfbLog.0 -d -m /opt/scripts/ luckyba+ 48 46 0 09:12 pts/0 00:00:00 /bin/sh /opt/scripts/ luckyba+ 49 48 0 09:12 pts/0 00:00:00 Xvfb :0 -screen scrn 1024x768x16 luckyba+ 57 1 0 09:12 ? 00:00:00 SCREEN -S x11vnc -L -Logfile /luckybackup/x11vncLog.0 -d -m /opt/scripts/ luckyba+ 59 57 0 09:12 pts/1 00:00:00 /bin/sh /opt/scripts/ luckyba+ 63 1 0 09:12 ? 00:00:00 SCREEN -d -m env HOME=/etc /usr/bin/fluxbox luckyba+ 65 63 0 09:12 pts/2 00:00:00 /usr/bin/fluxbox luckyba+ 75 1 0 09:12 ? 00:00:00 /usr/bin/python2.7 /usr/bin/websockify -D --web=/usr/share/novnc/ --cert=/etc/ssl/novnc.pem 8080 localhost:5900 luckyba+ 84 17 0 09:12 ? 00:00:00 /luckybackup/luckybackup root 2006 0 0 09:43 pts/3 00:00:00 sh luckyba+ 2031 59 0 09:43 pts/1 00:00:00 sleep 1 root 2032 2006 0 09:43 pts/3 00:00:00 ps -ef #
  4. I also get the "failed to connect to server" on my luckyBackup image. Ctrl+Shift+R does no good, neither does opening the URL in an incognito window. Attached the log and screenshots of the template. docker.log
  5. I still don't understand how it came to be that it was mounted again, and where the 16 GB fs came from, but I just gave up and ignored it and proceeded with the next steps. Looks good so far.
  6. I wrote this as a follow up to a previous post, but since I got no response I'll try with a new post. I have disk that is causing problems, so I wanted to remove it from the array. I found and started to follow the steps in "The "Clear Drive Then Remove Drive" Method". After 48+ hours finally the "clear an array drive" script finished, and I wanted to continue with the next step. However, at this point I find that the disk has been mounted again and a parity check is running. According to the main tab, the fs size is 16 GB, and 1.21 GB is used. A ls -al at /mnt/disk1 shows no files though. How did this happen, and more importantly, how do I continue?
  7. Memtest and extended SMART reports found no problems, but nevertheless reported uncorrect kept rising and Unraid reported read errors on the disk, so I decided I wanted to remove it from the array. I found and started to follow the steps in "The "Clear Drive Then Remove Drive" Method". After 48+ hours finally the "clear an array drive" script finished, and I wanted to continue with the next step. However, at this point I find that the disk has been mounted again and a parity check is running. According to the main tab, the fs size is 16 GB, and 1.21 GB is used. A ls -al at /mnt/disk1 shows no files though. How did this happen, and more importantly, how do I continue? Please don't tell me I need to start over with the clearing script, it's getting ridiculous, I think my uptime/downtime ratio is getting close to 1:10 at this point. Submitted another diagnostics report.
  8. Alright, good tip about Syslog Server! I just enabled it, so hopefully there will be better diagnostics next time it happens! Thank you! No, I haven't. My rendition of what happens is the my Plex docker is waiting for disk io, caused in some way by my gaming VM trying to reserve something that is in use by docker. I don't think memory has anything to do with it, but I am in no position to rule anything out. I'll do that when there's a chance, still waiting for extended SMART reports.
  9. Thanks for responding! Good point, I haven't tried extended tests on the other disks, I'll start it immediately! It took a long time to finish the last time, so I expect it to run overnight and be ready some time tomorrow. Don't understand this part. Do you mean you are repeatedly running parity checks? Sorry for being unclear, I'll describe the timeline and hope that clears it up: I was forced to do a hard reset due to a docker stuck waiting for IO (as mentioned in my other post), and that in turn forced a parity check which takes around 24 hours. When that finished (with 0 errors) it didn't take long (a few hours maybe) until the same thing happened again. This time, after another ~24 hours, the parity check had found and corrected 1 793 sync errors, and another SMART warning of "reported uncorrect" on disk1 (up to 5 from previous value of 4). So, I ran another parity check manually, and waited for another ~24 hours for that to finish. This time it came back with 0 errors, but I wanted to be sure that it wasn't a one time thing, so I ran another manual check that also came back with 0 errors. It was after this last manual check had finished that Mover was finally able to run as scheduled, and I woke up to it trodding along at ~50 kB/s. I don't trust my disks (consumer products not intended for this kind of use), and honestly I don't trust (how I'm using) Unraid to keep my data safe if I have a setup that only allows for one disk failure. So far, using Unraid has forced me to do a number of hard resets that seems to have harmed my disks (since the "reported uncorrect" has risen), so I have no desire to swap out a parity drive for another cache drive. Especially not given the extremely underwhelming performance of cache drives in Unraid in my setup to this point. Nothing unusual that I'm aware of. I have a Fractal Design Define R5 case with the disks mounted in the disk bay. They are connected via SATA cables to the SATA ports of my ASUS Z170 Pro Gaming motherboard, and to my EVGA SuperNOVA G2 850W powersupply via the supplied power cables. Thanks again for trying to help me! /Rickard
  10. Sigh. So I decided to try to make use of my cache drive after all, I thought that there must be some way it can be useful. So I stopped all my docker containers, moved the storage paths that I cannot have unprotected (like my database) out of the appdata share, made a backup with the backup app mentioned, set appdata share to prefer cache and ran Mover. The speeds were not impressive, but acceptable, so I decided to keep this setup. Because of the hard resets mentioned in my other posts, parity checks have been running more or less constantly since then, and since I used the Mover Tuning app to stop Mover from running during a parity check, tonight was the first night it ran. And. Sigh. It's still running. At a whooping 90 kB/s at the moment I'm writing this. So. Once again, I'm wondering: what am I doing wrong? I've attached another diagnostics zip.
  11. Did I post this in the wrong forum? If that is the case, is there a way to move it?
  12. I gave in and did a hard reset, so I guess this is more or less moot. I'm quite certain it will happen again though, so if somebody could help me understand why it happens, I'd be thankful. In the meantime, I will just keep the gaming VM on at all times, so this can't happen.
  13. Hi, I have a docker container (plexinc/pms-docker) that is "stuck" and can't be stopped, I think it's waiting for IO. Is there any way to get it out of this state without a hard reboot? I want to avoid them as much as possible, since parity checks take 20+ hours and make the system unreliable. A little context: I am running "Unraid Nvidia", and have to GPUs, a GTX 1080 passed through to a gaming VM, and a GTX 1660 set as visible to Plex to be used for transcoding. The gaming VM also has a USB controller passed through. This is the second time that I've tried to start my gaming VM and it fails and crashes the VM manager. Much like what spaceinvader one described will happen if you're using a GPU for transcoding and then trying to start a VM with the same GPU passed through. But of course this is not my case, since I have two different GPUs for this. Both times this has happened, Plex has failed to enter a stopped state after I try to stop it, and there is a process in ps named "wait" that can't be killed. Also, as I'm writing this, I tried to run the command "nvidia-smi", and it "hangs". As in I type "nvidia-smi" and press enter and nothing happens. Any help investigating would be appreciated! /Rickard EDIT: This is a post I made earlier, and the hard reset I am referring to was caused by this:
  14. Hi, I have a docker container (haugene/transmission-openvpn) that autostarts, despite the autostart setting being "off". Can somebody tell me what am I doing wrong? I've attached a diagnostic zip. I'm also wondering if there is a way to edit a container without it automatically starting when I save the changes. Thanks! /Rickard EDIT: Found a FAQ in Docker Engine forum:
  15. Hi again, Thanks for an extensive answer! My mover finally finished, and after reseating all cables in both ends I booted the machine and started an extended SMART test. It's been running for over an hour now and completed 10%, so I'll leave it over night again and will probably have to kill it in the morning. My issue with slow mover speeds is moot, I guess, since it finally finished and I will get rid of the cache or move to something other than Unraid, so the following are only my own reflections on cache drives in Unraid, and can be ignored. Thanks for explaining how the cache drive is used. I'm not sure I really missed your points, it's just that I don't want to have my appdata any less protected than my other data. I don't have enough connectors on my motherboard to connect another cache drive, and even if I did, I think it's absolutely not worth it. I have two parity disks to make sure I can suffer two disk failures and still have all my data intact. To upgrade to a cache pool, I would have to spend more money, and only get protection from one disk failure. It seems to me that you can't get uninterupted uptime (by not having to shut down VMs/dockers), protection against data loss (by writing to a parity-protected array) and speedy transfers (by using a SSD cache) with Unraid, and I must say I'm really surprised by that. The backup app you mention also requires the docker to be shut down to be backed up. That is absolutely true, and I'm not asking for that. A cache should, in my mind, be a subset of the underlying data for faster reads and/or writes. When I hear somebody talk about a cache, I think of a write-through or write-back cache, where your data always reaches the underlying storage either immediately (at the speed of the underlying storage) or at a later time (at the speed of the cache, up to the size of the cache). I've never thought you would have a cache that doesn't write back everything that is written to it to the underlying storage at least at some point. Anyway, this journey has been really interesting, and I'm thankful you took the time to try to help me. Cheers! /Rickard
  16. Hi, Thanks for your reply! I really appreciate it! This is what I mean with "I don't understand how to use the cache". Wouldn't that leave my always-on dockers and VMs completely unprotected, since mover won't move things that are in use? Sorry, I meant they are Yes, and I set it as such because the description is "Mover transfers files from cache to array" which is what I want if I want to get rid of the cache disk. It has space now because everything has been off for over 24 hours and mover has been running for over 10 hours, moving things off the cache. I don't know what you mean by "cache the initial data load", but I haven't tried to do anything actively other than make it stop filling up, and stop being extremely slow. In fact, I turned off every VM and docker image, and the cache disk kept filling up. Again, I don't understand how to use it. If I tell the domains share to use the cache, and I have a 1TB vdisk in there, would that not take all the cache space immediately? So if I have always-on VMs and docker images that is constantly accessing it's data, a cache disk is pretty much useless? I mean, if I expect there to be something on my Unraid system that is writing to the array at all hours of the day, there will be no "idle time". So every time mover runs, I will have to expect it to move things at 20 Mb/s, and also making my system extremely slow and unresponsive during that time. That is the opposite expected effect of having a cache for speed. This is kind of what I'm leaning at, and it is why I'm trying to get rid of it. What I don't understand, though, is that the system cannot be any more idle than it is right now, so why is it so extremely slow? Nothing else than mover is running, and yet it keeps moving files at ~20Mb/s. Ok, thanks for the suggestion! I'll definitely do that, but I'll have to wait for mover to finish, which at this rate will be sometime during midnight. Thank you very much for taking the time to answer and trying to help, much appreciated! /Rickard
  17. <TLDR>I'm getting ~20MB/s read/write speeds when Mover is moving from SSD cache to array, what am I doing wrong?</TLDR> Hi all, I'm very new to Unraid and the forums, so I apologize in advance for any frustration I will cause with my ignorance. I'm currently evaluating Unraid to see if it is for me, and in the beginning it all looked so promising so I decided to take the plunge and move everything I have in terms of storage into Unraid. I also bought a new 1TB SSD to use as a cache drive, so now my disk setup is: Parity 1: ST8000DM004 8TB SATA Parity 2: ST8000AS0002 8TB SATA Disk 1: ST8000DM004 8TB SATA Disk 2: ST8000AS0002 8TB SATA Cache: Samsung SSD 860 QVO 1TB SSD Unassigned pass through disk: Samsung SSD 970 EVO 1TB NVMe M.2 After I added the cache drive, I started getting constant warnings and errors about the cache being full. I fully admit that I don't really understand how to use the cache, and certainly understood even less in the beginning. I guess I just assumed if I added a cache drive and used the "Fix Common Problems" plugin it would tell me if I was using it in a bad way. Anyway, I got frustrated with all the constant notifications about the cache, so I changed the cache settings on all shares, I don't remember to what exactly, and started Mover manually. It started moving at an extremely slow rate, and then something went wrong. Maybe it was because I changed the cache settings while Mover was running in an attempt to make a difference since it had only moved a few gigabytes after a few hours , but the result was that the system was extremely slow and unresponsive, and Mover stopped working altogether. This went on for hours and nothing changed, so I tried to shut down Unraid without success. In the end I was forced to kill it by holding the power button. After it came online, it started a parity check that took many hours, during which Mover woke up and started moving stuff from the cache. This slowed down the parity check which in the end took ~21 hours (and resulted in 6101 errors), but it got there eventually. Mover still keeps running though, and it's still extremely slow at around 20 Mb/s. I think it's scheduled to start at 03:30 in the morning, so by now (14:15 here in Sweden) it's been running for over 10 hours and it's about half way done. The system is not doing anything else, the VM and Docker manager are both stopped. The cache settings right now are either "No" or "Prefer" on all shares, because I feel like I want to get rid of the cache drive. It's only causing me frustration, and as I said, I don't understand how it's supposed to work. Is there anyone who can help me figure out what I'm doing wrong? I attached diagnostics and a screenshot showing the Main-tab with read/write speeds. Worth noting: 1. One of the drives, the ST8000DM004 used as disk 1 has gotten three "reported uncorrect" warnings the past few days. It's a quite new disk, so as long as this value stays at 3 I'm writing it off as one time issues caused by the troubles I've had setting the array up in the beginning. 2. The other array drive, the ST8000AS0002 used as disk 2, has write cache disabled and it ignores my attempts to enable it. If you've made it this far, thank you for taking your time to read all of it. Sorry for all the faux-pas I've no doubt commited. /Rickard