Jump to content

Ambrotos

Members
  • Content Count

    113
  • Joined

  • Last visited

Community Reputation

12 Good

About Ambrotos

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

  1. Yeah, I actually didn't wind up using it after all and just went back to customized BIOS fan curves. Still nice to finally have all the RPM and temp values available to the System Temp plugin -A
  2. @Forty Two man, am I glad I found your post. I've been scratching my head for a long time about why my Asus Z270 Prime board was detecting the NCT6775 module but not detecting any of the PWM controllers attached to it. I tried all the other posts' suggestions about making sure you've got the latest lm_sensors and forcing modprobe address etc. Your acpi_enforce_resources=lax tip was the missing piece! This is the only place I've seen reference to that. Out of curiosity, where did you find that?! -A
  3. Take a look through this thread from back when CrashPlan originally changed their pricing model and caused the exodus. The strategy I described back then is still pretty much what I do today, with the exception that I not longer use the ProFTPd plugin. It's been working great for 3+ years. https://forums.unraid.net/topic/61234-moving-from-crashplan-to-duplicati-requesting-guidance/?tab=comments#comment-600970
  4. That error message is referring to the configured Access Mode of the UD volume you've configured for that container. Edit the docker, switch to the Advanced View, edit the volume configuration that you have mapped to your Unassigned Device, and change the Access mode from the default Read/Write to RW/Slave. -A
  5. Hm. You're probably right. I was never super clear on the difference between volumes and binds. Thanks for the clarification! -A
  6. I know this is a bit of a zombie thread, but I recently ran into the same thing and thought I'd post here for anyone else who's having trouble with this docker. The reason that the nxfilter-base docker throws the Java exception seems to be that it's not able to deal with an empty conf folder. In unRAID-land we're used to dockers which will populate their /conf folders with default configuration when they're empty on first startup. Whether it's intended or not, that doesn't seem to work with this docker. When you don't map any host folders to the container's /nxfilter/conf then it starts up and uses the configuration files in the image itself. My quick hackey solution was just to start the docker with all the port and folder mapings *except* the /nxfilter/conf one. I temporarily mapped /mnt/user/appdata/nxfilter/conf : /tmp/conf, and connected to the container using docker exec -it <container-id> /bin/bash. Then I just got the default config out of the image and into my host with a cp -r /nxfilter/conf/* /tmp/conf, stopped the container, deleted the temporary mapping, and added the usual /mnt/user/appdata/nxfilter/conf : /nxfilter/conf. After that, it fired up no problem. Hope someone finds this useful. -A
  7. Back when Crashplan changed their business model I jumped ship and started searching for alternatives. I went the Duplicati + online storage route, and selected Backblaze B2 for the online half. Actually, I just did a forum search and there there was a conversation about it here: Two-and-a-bit years later, and I can confirm that this is still working great for me. I've got about a terabyte stored in B2, and my bill last month was just over $3. Hope that helps. -A
  8. @Taddeusz thanks for the tip. I made the change, rebooted, and haven't seen the message recur since yesterday. Out of curiosity, does anyone have an idea if this is actually a difference between 6.6 and 6.7, or did I just happen to coincidentally notice it after the upgrade and this has been happening for a while now?
  9. I had considered that, but I did have visions of one day finding some spare time to install a graphics card and build a Steam in-home streaming VM. Ideally I'd like to figure out how to fix this without disabling IOMMU -A
  10. Since upgrading to 6.7.0 a couple days ago, I have started seeing the following message in my system log. May 16 07:00:02 nas kernel: DMAR: [DMA Read] Request device [03:00.0] fault addr ffabc000 [fault reason 06] PTE Read access is not set Some quick Googling suggests that this is related somehow to IOMMU, though I don't use hardware passthrough for any of my VMs and anyway I've confirmed that IOMMU is reported as enabled by unRAID. The error message is similar to one raised during the 6.7RC. Maybe the patch that was included to fix the previous issue had an unintended side effect? Unlike the issue reported by Duggie264, I am not using any HP240 controllers. Mine are all IT reflashed m1015s or H310s. Also, note that the PCI device that it's complaining about is my Intel nVME drive that's currently not part of the array and is mounted by UA. Maybe that's related? Attached are my diagnostics. Does anyone have any thoughts on this? Cheers, -A P.S. - I should mention that I upgraded direct from 6.6.7. I don't play with RCs on this server, I have a test server for that. nas-diagnostics-20190516-1634.zip
  11. Yup, I noticed that there was an update to the plugin this morning. Looks good! Thanks. -A
  12. Is it just my system, or has anyone else noticed that the Settings icon for NUT doesn’t display anymore since the January 24th update to fa font? I initially thought it was just a browser cache thing, but I’ve since tried multiple browsers, multiple computers, etc. The NUT icon in the plugins page loads fine, but I’m assuming that’s because it hasn’t been changed to be “awesome” (Running 6.6.6 if that matters. I haven’t had a chance to try out the 6.7RC yet) -A
  13. Ah yes, I do see the mlx4_core reference in the second trace message there. I must have made a typo when I searched the first time and didn't find anything. So alright, is Mellanox a common element of this issue? @AcidReign, what drivers are you using? @Hoopster? -A
  14. I reported a similar issue a while ago which at the time I suspected might have been related to the 10G Mellanox drivers I was using not playing nicely with macvlan. I don't see any reference to the Mellanox drivers in your stack trace though; it looks like you're using Intel drivers. So maybe this is a more common issue than I'd assumed. I haven't really been following it since I last saw it in August. I can confirm at least that it was present in version 6.5.3. Is it safe to assume that you're running 6.6.3? If so, that begins to put a range on the affected software versions... Anyway, as I mentioned in my post linked above, I just avoided the issue by removing VLANs and using multiple hardware NICs. I'm just chiming in here to report that I've seen this issue as well. Cheers, -A
  15. Yes, I saw that thread. I stuck with "Dark" -A