• Content Count

  • Joined

  • Last visited

Community Reputation

10 Good

About bling

  • Rank

Recent Profile Visitors

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

  1. just upgraded. posting what i had to do for others in case they had similar issues to me. docker-compose all of my containers are in a single docker-compose.yml file and that reloaded without any problems after the array was started. hooray! ssh per the release notes, a password is required now. i enjoy the convenience of no password so i ended up just setting up private key authentication instead. and...that's it. pretty seamless upgrade. thank you!
  2. the image doesn't have any time zone info so you need to add a volume mount for /usr/share/zoneinfo
  3. feature request. can we add the ability to disable certain checks? for me, notably all of the checks for docker (updates, templates, etc) are creating false positives because i've completely swapped everything for docker-compose. however, even if i didn't do that, i'm sure there's a ton of people that would prefer checking for docker image updates to be disabled. "if it ain't broke, don't fix it". this is especially true when a new docker image introduces a breaking change, which could be especially bad if it corrupts the appdata and there are no backups.
  4. stumbled upon this bug report when i noticed the same thing today. when using private shares, any files written are owned by the logged in user, and not 'nobody', which can cause various annoyances later since so many things assume everything is owned by nobody. i fixed it by modifying the samba config, you can add the following to /boot/config/smb-extra.conf [global] force user = nobody force group = users
  5. you need to set the network type to 'none', so that the --net in the extra params will work. also, if your child container has a port exposed you need this defined on the parent container instead otherwise you can't access it.
  6. hit the 'add container' button at the bottom of the docker tab in unraid and fill in the details. as for privoxy, that's just a proxy that allows other applications to reuse the existing VPN connection of the container. prior to the introduction of --net, this was how you got other containers to reuse a single VPN connection. however, it also means that the software must support specifying a custom proxy server. with --net, you don't need to define a proxy configuration in any client running in a child container because it's network gets isolated to only use what the parent cont
  7. there are tons on docker hub. pick one and add it manually.
  8. instead of. using --net replaces any existing method for achieving this. you don't need to set up proxies or anything because any "child containers" will reuse the network of the parent. so all you need to do is find a docker container (there are tons) that do openvpn + a kill switch as the parent and you're good.
  9. FYI you can put "--net=container:foo" in the extra params to make any docker container reuse the network of an existing container (example here is that "foo" is the docker container connected to the VPN). the recently released 6.8.3 makes this work again without the need for workarounds.
  10. it's the PSU. since i swapped with a spare it hasn't crashed regardless of what workloads i threw at it. did a full parity check and some bits needed correcting.
  11. memtest passed overnight. rebooted unraid in safe mode, and within moments of a medium workload within a docker container, reboot! i checked /proc/sys/kernel/panic, and it's set to 0, which is the default meaning it will not auto-reboot. just swapped out the PSU with a spare...wish me luck!
  12. Another bit of useful information, I caught it doing a random boot in the middle of a reboot! I SSHed into the box, was tailing the log, before emhttp started up I lost connection.
  13. It's my old rig that I repurposed as a NAS server. 4790k, asrock mobo, 16GB RAM. It's been rock solid since day 1 when it was running Windows. Recently when I rebuilt it for unraid, all the hardware remained the same except for new hard drives, a recently replaced PSU under warranty, and a new UPC. I'm running memtest right now, directly plugged into the wall.
  14. Sigh....while I was rsyncing from the array back to a freshly formatted XFS cache disk, the server hard rebooted again. So I guess that rules out the file system. I had putty tailing the syslog at the time and nothing was logged during the reboot. I'm also tailing dmesg now...
  15. Logged in this morning to my server and noticed that a parity check was running, which I thought was odd. I was like hmmmm...I didn't start that. Maybe I had it scheduled for end of the month? Checked that, nope -- it's off. Then I realized that the uptime was an hour. My machine is 24/7 and has been rock solid for 2-3 weeks. From there, I was experimenting with a new docker app, and then bam!! Random reboot. From here, I turned off docker/VMs and let the parity check run to completion. Thankfully no errors. Just now, again, playing around with a docker app, and