dtempleton

In trying to make a new docker instance using docker-compose I encountered this error that prevented the image download: ERROR: Get https://lscr.io/v1/_ping: x509: certificate has expired or is not yet valid Googling around this seems to be related to an incorrect clock setting on the local machine, or a certificate that has actually expired. The fixes I cound (one on CentOS) reference a directory not present in UnRAID. How can I reset my clock on UnRAID or obtain a refreshed certificate? TIA Dennis

I'm resurrecting an ignored server and preparing for an update. HOWEVER, as it is now the WebUI doesn't load in my normal environment. I checked if this might be due to a plugin conflict by rebooting in Safe Mode, and sure enough, the WebUI loads in Safe Mode. Now I want to remove (or disable) suspect plugins one or a few at a time to find the conflict. How can I do this? I looked in /usr/local/emhttp/plugins and (in safe mode) only Dynamix apps and UnRAID are listed. The go script auto_installs those so marked in /boot/packages/ Can I just relocate these to say /packages_inactive to get them not to load, or am I missing a simpler way.? TIA

Thanks, that is truly helpful!

I’ve been out of the country and away from my server since version 6.3.5. I set it up this week and find it still works (one drive failure and a new one preclearing now. The GUI suggests updating to 6.5.3 while CA update requires 6.9+ I have 2 parity drives, 8 data drives and an SSD cache drive. My goal is to run SAB etc, have family backups, and run a PLEX server. My question is whether there is a logical path to updating UnRAID. How can I tell if my hardware supports the newer versions? Is it rational to just stay at 6.3 or am I missing so much that’s silly? I do miss having a working CA to set up a Docker. thanks! Dennis

+1 for an integrated Docker-compose

Hi; I installed and ran this plugin to successfully clear a disk, which I set aside as a backup. I have another to preclear, and (without rebooting the server) I plugged into the same slot. Opening the preclear plugin page, the drive is detected as sdk, and the correct serial number is presented for the new drive. however, the report says "preclear finished successfully" which relates to the previous drive. I can't figure out what to do to re-initialize a new preclear. I haven't resorted to rebooting the server or reinstalling the plugin, but have tried just about everything else, clicking every link like a self-educating monkey. This doesn't happen very often, of course, but am I missing a switch to run preclear again? Thanks Dennis

You should be able to put those extra paramters in the <ExtraParams> </ExtraParams> tag in the template xml. In the webgui it's under advanced view and Extra Paramters. Actually I found some advice in Jon's "Get Fancy with Docker" pinned thread about it, using a different avenue.

As a suggestion for the FAQ, though possibly not frequent: How can we manually modify the 'docker start' autostart command that seems to be populated through the template? Background: I have a background script that requires launching a container (through 'docker run', not 'docker start') with flags including --rm and -cpuset-cpus. I can't see how to include any of these options in the template. I can keep a copy of the run command (with mappings) handy for use through ssh when the server is rebooted, but it would be great to have this custom container autostarted, or restarted. D

Thanks! Somehow that was not clear to me. For other interested parties, what worked is this command in /boot/config/go: setsid /boot/config/plugins/cache_dirs -w -d 6 -i Media -i Misc -i Comedy -i Music\ Videos resulting in this log report: Sep 10 15:03:00 Tower cache_dirs: ============================================== Sep 10 15:03:00 Tower cache_dirs: command-args=-w -m 1 -M 10 -d 6 -p 10 -U 50000 -i Media -i Misc -i Comedy -i Music Videos -B -a -noleaf Sep 10 15:03:00 Tower cache_dirs: vfs_cache_pressure=10 Sep 10 15:03:00 Tower cache_dirs: max_seconds=10, min_seconds=1 Sep 10 15:03:00 Tower cache_dirs: max_depth=6 Sep 10 15:03:00 Tower cache_dirs: command=find -noleaf Sep 10 15:03:00 Tower cache_dirs: version=1.6.9 Sep 10 15:03:00 Tower cache_dirs: ---------- caching directories --------------- Sep 10 15:03:00 Tower cache_dirs: Comedy Sep 10 15:03:00 Tower cache_dirs: Media Sep 10 15:03:00 Tower cache_dirs: Misc Sep 10 15:03:00 Tower cache_dirs: Music Videos Sep 10 15:03:00 Tower cache_dirs: ---------------------------------------------- Sep 10 15:03:00 Tower cache_dirs: cache_dirs process ID 5599 started, To terminate it, type: cache_dirs -q

I wonder if this is related to the error I see in syslog when cache_dirs starts up on boot: Sep 10 12:02:00 Tower cache_dirs: ============================================== Sep 10 12:02:00 Tower cache_dirs: command-args=-w -m 1 -M 10 -d 6 -p 10 -U 50000 -i /mnt/ -B -a -noleaf Sep 10 12:02:00 Tower cache_dirs: vfs_cache_pressure=10 Sep 10 12:02:00 Tower cache_dirs: max_seconds=10, min_seconds=1 Sep 10 12:02:00 Tower cache_dirs: max_depth=6 Sep 10 12:02:00 Tower cache_dirs: command=find -noleaf Sep 10 12:02:00 Tower cache_dirs: version=1.6.9 Sep 10 12:02:00 Tower cache_dirs: ---------- caching directories --------------- Sep 10 12:02:00 Tower cache_dirs: Sep 10 12:02:00 Tower cache_dirs: ---------------------------------------------- Sep 10 12:02:00 Tower cache_dirs: ERROR: included directory "/mnt/" does not exist. Sep 10 12:02:00 Tower cache_dirs: cache_dirs process ID 5533 started, To terminate it, type: cache_dirs -q I *think* the array is started by that time. From all external evidence the /mnt/ volumes are being cached. D

I would have thought that made the disks spin up, but you must mean accessing the directories that were previously stored in RAM. Yes, this I didn't understand at all. Thanks for this explanation, and for other newbies, cache_dirs has made a large difference in my day to day usage of unRAID. Dennis

An update following further experimentation. I haven't been able to get logging to work, but from a post I've lost now I learned that the flag -d to set the depth of the menu collection is essential at least on large directories. I now launch the script with /.../cache_dirs -w -d 4 In Finder or Pathfinder (osX) large directories now open in fractions of seconds rather than tens of seconds, and the drives are not spun up. This is transformational and makes unRAID workable for once. I think the issue is that without specifying the -d depth the default is something like 999 subdirectories that essentially never completes. For me -d 4 is enough to preview my media files. It's telling that opening that fifth directory depth now takes tens of seconds again. Another point is that last night I went through a powerdown and one of the disks wouldn't unmount because it was busy. The culprit was a "find" process that I think was part of the cache_dirs looking to complete its 999 depth survey. Not sure about that but today with -d 4 there is not a long lasting 'find' process. Thanks again for this script. Dennis

I just installed 1.6.9 and posted some issues I have with 6b6, but I had a more conceptual question. I see the point of moving the directory lists off of the drives to prevent platter spin-up, but I wonder if having the option to save the directory data to an SSD drive instead of memory might be a big advantage for those of us who have an SSD cache. Personally I have maxed out my RAM at 4 GB but have a 256 GB SSD sitting there doing nothing most of the time. If cache_dirs wrote to the cache drive instead of memory, I would be able to use more of my memory for important stuff, like... Maybe it's not as simple as it sounds, but I haven't seen discussion of that. Thanks, Dennis

I've installed cache_dirs 1.6.9 on unRAID 6b6, and I can't get logging to work, and similarly can't tell if it's doing anything. I invoked the script with /boot/config/plugins/cache_dirs -w while my disks were sleeping and over a couple of minutes all of them spun up. seems right. Putting the disks back to sleep loading the directory contents in mac Finder or Pathfinder still seems slow, but once the directories are open the disks (for the most part) are still spun down. OK. Then I tried to move the process to the Front, to see what was happening First, the /boot/config/plugins/cache_dirs -F command gave no screen output for several minutes, and no cursor. ctl-C to cancel, and /boot/config/plugins/cache_dirs -q says no process running. Trying out the logging function: root@Tower:/boot# /boot/config/plugins/cache_dirs -l on Logging enabled to /var/log/cache_dirs.log root@Tower:/boot# ps PID TTY TIME CMD 3578 pts/4 00:00:00 ps 31741 pts/4 00:00:00 bash root@Tower:/boot# /boot/config/plugins/cache_dirs -q cache_dirs not currently running root@Tower:/boot# cat /var/log/cache_dirs.log root@Tower:/boot# It looks like the process is not started, and there is no log written. While the standard evoke root@Tower:/boot# /boot/config/plugins/cache_dirs -w cache_dirs process ID 3868 started, To terminate it, type: cache_dirs -q root@Tower:/boot# ps PID TTY TIME CMD 3868 pts/4 00:00:00 cache_dirs 3884 pts/4 00:00:00 cache_dirs 3904 pts/4 00:00:00 find 3908 pts/4 00:00:00 ps 31741 pts/4 00:00:00 bash root@Tower:/boot# Seems to start up process(es) Maybe I shouldn't worry since it seems to work, I just can't get the evidence for it. Plus, it's not done much to my Mac Finder experience. Despite my issues, I am grateful for this. Dennis