kmwoley

Members
  • Content Count

    37
  • Joined

  • Last visited

Community Reputation

8 Neutral

About kmwoley

  • Rank
    Newbie

Recent Profile Visitors

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

  1. I dislike this solution for a few reasons. The primary of which is that passing in the entire BT bus into a Docker container only works if it's running as privileged and on the host network IIRC. In my configuration, I run my containers in VLANs for network isolation, making it such that they can't access the Bluetooth devices. If the BT support were removed from the host OS, I'd then have to create/maintain a Docker container in a higher-permission config just to run a simple Bluetooth script. Feels like overkill to go in that direction to me. It's nice that there's multiple ways
  2. @dmacias I just upgraded to 6.7.2. Is there a reazon bluez would have disappeared from NerdPack? It was super useful. Thanks!
  3. Thank you - super useful. I'm starting to do some dev on Unraid for a really basic project and needed to get `make` installed.
  4. Does anyone know if DevPack is supported on 6.7.0+ ? I'm looking to get make installed but was hesitant to install DevPack given that it hasn't been updated in a while and the report above of issues. Thanks!
  5. Thanks for your help. I kinda get it, but when looking at the disk usage before making these changes I would have also said that I had 31GB free. Am I interpreting that first `btrfs fi usage...` command wrong? How am I to know in the future when a balance operation is required before I "run out of space"? I ask because I'd like to write a cron job that warns me before I run out of space. Thanks again for the help.
  6. Thanks for the pointer. After reading that thread, here's what I did... I'd appreciate if you could check my understanding and help me to know how to avoid this in the future. 1) Checked the space reported by btrfs... root@lenny:~# btrfs fi usage /mnt/cache Overall: Device size: 352.13GiB Device allocated: 238.48GiB Device unallocated: 113.64GiB Device missing: 0.00B Used: 182.85GiB Free (estimated): 84.24GiB (min: 84.24GiB) Data ratio:
  7. Done. Attached to the original post. Sorry I left those off. Thanks!
  8. Hey Folks, I could really use some help. I've run into trouble that I noticed after having upgraded to 6.7 from 6.6.7, but it might not be related to the upgrade. I first noticed that Docker was filling up /var/log and my Docker containers were stopping on me. I turned off a number of my Docker containers and rebooted to see if I could isolate which Docker was log-spamming. That helped, but eventually my docker containers stopped again after a few hours, complaining about running out of disk space (on /mnt/user/appdata) where there's clearly enough disk space. In t
  9. I cannot tell you why or how, but after downgrading from 6.6.7 -> 6.6.6 four days ago, and then upgrading again today from 6.6.6 -> 6.6.7 the issue I reported before (i.e. Custom Network Types not appearing in Docker Container configuration) appears to have gone away. 🤷‍♂️
  10. Confirmed. Rolling back to 6.6.6 solved this issue. Container configs can now select the Custom networks for Network Type.
  11. Hey folks - I ran into a problem with this upgrade. I have custom network's configured for Docker (MACVLAN). After the update, all of my containers started just fine. But one of them started to have some networking issues and I started investigating. I tried changing a setting in that container and when I saved the container, it disappeared! Looking deeper, I notice now that under the networking options for the container config any network which was using a MACVLAN network (e.g. br0.55) now shows Network Type of "None" and the custom networks for MACVLAN are
  12. You're right that masquerading is typically done for traffic exiting your local network, but it can also be used for things like the OpenVPN config. In the case of OpenVPN it's handing out IP addresses to the clients in a different range than the local network. In the bridged docker network configuration installation of OpenVPN, those remote client IP addresses were being masqueraded somewhere along the path before they left the host so they showed up as my host server's IP on the local network. Switching to host networking exposed those client IPs to the local network.
  13. I honestly don't have a clue then how OpenVPN-AS (or any other VPN) running in Docker host networking mode is masquerading it's client traffic, then. It just doesn't make sense to me that there's no way to masquerade the OpenVPN client IP addresses on their way out the door. In the end, I gave up trying to get my host to masquerade the traffic and instead added static routes for my OpenVPN client address space to my networking stack outside of the unraid host. It's a fine solution, just annoying. If someone trips across this post in the future and finds a solution, I'd