bland328

Members
  • Content Count

    101
  • Joined

  • Last visited

Community Reputation

20 Good

About bland328

  • Rank
    Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah--that's excellent, thanks. The new approach of passing the appropriate $disk or $dev to check_temp (rather than just $name) makes a bunch of sense.
  2. Hmm...very strange--the code you posted doesn't match the version of the monitor script I'm running. On my 6.9.2 install, /usr/local/emhttp/plugins/dynamix/scripts/monitor calls check_temp thusly: // check array devices foreach ($disks as $disk) { .. // process disk temperature notifications check_temp($name,$disk['temp'],$text,$info); .. } // check unassigned devices foreach ($devs as $dev) { .. // process disk temperature notifications check_temp($name,$temp,$text,$info); .. } This explains why the tweak I posted makes check_temp work properly on my system, but does
  3. tl;dr: It appears to me that Unraid 6.9.2 doesn't honor device-specific temperature notification settings for Unassigned Devices for a straightforward reason that is easily fixed. Now that I have two unassigned NVME drives in my Unraid server, the annoyance of over-temp notifications that ignore the per-device settings has doubled, so I've come up with what is hopefully a true fix, rather than a workaround, in the form of a small change to the check_temp function in /usr/local/emhttp/plugins/dynamix/scripts/monitor. Here's the diff for /usr/local/emhttp/plugins/dynamix/
  4. +1 Under 6.9.2, the smart-one.cfg file behaves properly, in that GUI changes show up in the file and vice-versa. However, I still get over-temp notifications in cases that I should not.
  5. I'm unsure on the right priority for this--it is certainly not an Urgent data-loss emergency, but also seems more than Minor, as it can be a significant problem for those relative few unlucky enough to run into it.
  6. Problem description Under Unraid 6.9.2, mover appears to leave symbolic link files targeting non-existent files ("broken" symlink files) in the cache forever. Though such symlinks are commonly called "broken" or "invalid" symlinks, those titles are a bit misleading; in truth, though they "feel" weird, they are perfectly legitimate file system objects with a variety of purposes and reasons for existing, so I hope/assume this is simply a bug and/or oversight in mover. How to reproduce Simply make a symlink to an invalid path in a user share that uses the cache,
  7. tl;dr: Why am I being asked to re-provide my encryption key when upgrading a data drive? I've been an Unraid user since version 2013, and understand quite a bit about how and why Unraid does what it does. Today, however, I'm confused, and can't figure out if Unraid is doing something unexpected, or if I'm being dense, since I haven't replaced a drive in a couple years. I'm replacing a healthy 4TB drive with a new 8TB drive, so I stopped the array, set the 4TB drive to "no device," shut the system down, swapped out the old drive for the new, powered up again, and selecte
  8. I'm having a problem with CA that's new to me, but I'm not clear if it started with version 2021.02.27, or earlier. The problem is that when I do a DockerHub search, the chain-looking "link" icons don't do anything when clicked. And when I hover, the popups all read "Go to DockerHub page ca_href" I'm happy to gather more information, if useful.
  9. Glad to hear it helped! For the record, today the Unraid web GUI was draaaaagging...and I discovered these "worker process...exited on signal 6" messages rapidly spamming /var/log/syslog again. So, I went hunting for stale Unraid sessions open in browsers on other computers, and found two. When I closed one, the spamming slowed, and when I closed the other, the spamming stopped.
  10. Thanks so much for creating the Wallabag docker template! I'm trying to use it for the first time, and keep running into Error 500, and seeing this at the end of the log: 2021/01/25 15:54:14 [error] 201#201: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught RuntimeException: Unable to write in the cache directory (/var/www/wallabag/var/cache/prod) 192.168.1.226 - - [25/Jan/2021:15:54:14 -0600] "GET / HTTP/1.1" 500 31 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36" in /var/www
  11. I was just watching my syslog being spammed with nginx ... worker process ... exited on signal 6 2-3 times/second, and immediately upon finding and closing four stale Unraid web GUI tabs open across two machines, it stopped. Hope this helps someone.
  12. tl;dr: After migrating Docker and VM storage to Unassigned Device /mnt/disks/nvme, when I stop the array and that drive unmounts, I'm left with a /mnt/disks/nvme directory containing appdata, domains, and system dirs that each contain proper-looking directory structures, but no files. I recently migrated Docker and VM storage to a /mnt/disks/nvme volume mounted by the UD plugin (carefully updating all container configuration files and even the dockerMan template files along the way), and everything seems to be working well. But, as described above, I've noticed strange
  13. tl;dr: Improve handling of the uncommon situation that the mover can't move some files from cache to array because they unexpectedly already exist on the array. In Unraid 6.8.3, it appears that if a file exists on the cache drive (e.g. /mnt/cache/foo/bar.txt) and also on the array (e.g. /mnt/user/foo/bar.txt), then mover simply leaves the file on the cache drive forever. I recognize that this situation shouldn't naturally occur, but *shrug* things happen. I can see four problems with this situation, whenever it somehow occurs: Endangered data (since
  14. Enhancement request: Not a huge deal, but it would be lovely if Unassigned Devices would report not just "luks" as the filesystem for encrypted disks, but also the effective filesystem type (e.g. "luks:xfs" or something to that effect). Thanks for all the work on Unassigned Devices--it's fantastic!