rockard

Yes, it works perfectly now! Thank you so much!

Hi! I have LuckyBackup set up to send mail upon completion. Since June 13 I haven't recieved these mails, and when I test it manually in the GUI I see the following error message: trying to send an email . . . command: sendemail exit code: 1 output: Use of uninitialized value $2 in concatenation (.) or string at /usr/share/perl5/IO/Socket/SSL.pm line 792. Jun 20 11:19:22 684d7acda080 sendemail[479]: ERROR => TLS setup failed: hostname verification failed Has something connected to Perl/SSL been updated in the image causing this?

Sorry for bringing up an old question, but I'm struggeling with changing the locale. The "kdeglobals" file doesn't seem to exist in the image anymore (looks like it's based on Debian now?), and I think I'm now supposed to change the USER_LOCALES variable passed to the image instead. However, I can't find a locale within the supported list with English language and ISO-8601 dates. I stumbled upon the only way I find to get the desired output, and it is to set it to a non-English locale with ISO-8601 dates, surrounded by ''. For example 'sv_SE.UTF-8 UTF8'. If I set it to this, I will get English language, and ISO-8601 dates. If I skip the '' I will get Swedish language and ISO-8601 dates. This works, but it feels fragile, as it looks like unintended behaviour that might change at any time. Is there anything I'm missing, or am I best of using this "workaround" for as long as it works?

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?

Fantastic, many, many thanks!!!

The VNC log file from the container has errors, attached an excerpt from it vnc.log

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/start.sh 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/start-server.sh luckyba+ 17 16 0 09:12 ? 00:00:00 /bin/bash /opt/scripts/start-server.sh luckyba+ 46 1 0 09:12 ? 00:00:00 SCREEN -S Xvfb -L -Logfile /luckybackup/XvfbLog.0 -d -m /opt/scripts/start-Xvfb.sh luckyba+ 48 46 0 09:12 pts/0 00:00:00 /bin/sh /opt/scripts/start-Xvfb.sh 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/start-x11.sh luckyba+ 59 57 0 09:12 pts/1 00:00:00 /bin/sh /opt/scripts/start-x11.sh 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 #

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

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.

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 https://wiki.unraid.net/Shrink_array 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? eru-diagnostics-20200518-1836.zip

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 https://wiki.unraid.net/Shrink_array 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. eru-diagnostics-20200518-1836.zip

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.

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

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. eru-diagnostics-20200428-0849.zip

Did I post this in the wrong forum? If that is the case, is there a way to move it?