Just a guy. Just a fella. Subject to say silly stuff.

Alternatively @marighost@lemmy.zip.

Formerly @marighost@lemm.ee.

  • 4 posts
  • 26 comments
Joined 1 year ago
Cake day: June 5th, 2025

Howdy Selfhosters!

A family member who does not live in my state recently got a new PC, and asked for my help in setting it up. Since it can’t be done in person, I’ll have to do this over the phone. Problem is, I don’t really want to walk them through all of the steps (download Firefox, ublock origin, uninstall W11 bloat, etc) over the phone. I was hoping there exists a software that I could host on my Linux machine (I am able to port forward/host externally if necessary), and instruct them over the phone to download the “other end” (client-side) of the software so that I can remote in and set their PC up myself.

I checked out the awesome-selfhosted list and found that most of the remote access softwares are mainly for SSH servers. I did check out Guacamole, but I’m not sure I understand how to utilize the software. Any help and suggestions are welcome. Thank you everyone!

  • Is Linus getting paid by Microsoft to dissuade people from using Linux? Obviously he’s not, but every time he does one of these videos he just acts like a bumbling fool not being able to figure out the most basic of things. He’s trying to use Pop!_OS with COSMIC, which I understand is still full of issues. Meanwhile the other guy is trying to install a game that requires kernel AC and TPM secure boot (PUBG). It’s like he keeps engaging with Linux in bad faith.

  • Regarding CGNAT and Port Forwarding: I too am behind CGNAT with my ISP, and my solution to this is renting a cheap VPS (I use Contabo, others might have different recommendations) and installing Pangolin. It’s a tunneling software that uses some UDP fuckery to hole-punch straight through the network with their Newt tunnels. I use this so my friends and family can access my Plex and Overseerr requests.

  • The only logs from Pangolin are from me accessing https://overseerr.dom.tld. From Plex’s GUI console though, I get this:

    Request: [172.18.0.2:46974 (WAN)] GET / (6 live) #18eb GZIP Signed-in
    Completed: [172.18.0.2:46974] 401 GET / (6 live) #18eb GZIP 0ms 464 bytes (pipelined: 1)
    

    That 172.18.0.2 is the IP of the Newt container (that subnet is its bridge network, anyway). So it’s making some request to Plex and receiving a 401?

    From Mozilla:

    The HTTP 401 Unauthorized client error response status code indicates that a request was not successful because it lacks valid authentication credentials for the requested resource.

    So what would cause Plex to throw a 401?

Evening 'hosters,

I have been banging my head against my desk all day and could use some help. I seem to be the only one with this issue, so I’ll lay it out: I have a Pangolin instance hosted on a remote VPS with a Newt tunnel installed via Docker in a Debian 13 VM on my NAS. Within Docker, I have Plex, Jellyfin, and Overseerr (just for testing currently). All services are accessible via the LAN IP of the VM and their respective ports.

(Yes I know Plex is stinky, but my mom’s gotta watch her shows.)

I have three resources set up in Pangolin for each service, pointed at the LAN IP of the VM, the port, and the correct Newt tunnel, with a corresponding https://service.domain.tld/ record in Pangolin. Overseerr works flawlessly, without any additional input. Plex and Jellyfin, however, does not work. The resource monitoring module on Pangolin remains “unhealthy,” and neither service can be accessed remotely.

Here is how the Pangolin resource is configured:

szBlQiB4NUDqbg8.png

After doing tons of searching and reading, the general consensus for configuring Plex is to add https://service.domain.tld/ (noting the :443 at the end), disabling Remote Access from the menu, and disabling the Plex Relay setting. I’ve tried just about every combination of these settings, and none of these seems to bring the Pangolin resource online (which I figure I need to do to access it remotely).

Here is my compose.yml for Plex:

spoiler
services:  
  plex:  
    container_name: plex  
    image: plexinc/pms-docker  
    restart: unless-stopped  
    ports:  
      - 32400:32400/tcp  
      - 8324:8324/tcp  
      - 32469:32469/tcp  
      - 1900:1900/udp  
      - 32410:32410/udp  
      - 32412:32412/udp  
      - 32413:32413/udp  
      - 32414:32414/udp  
    environment:  
      - TZ=America_New_York  
    network_mode: host  

(Pretend there are volumes mounted in there, I removed them here for brevity)

I know setting network_mode= host and defining the ports is redundant, I was playing around with Bridge mode in some helpless attempt to get this thing working. I mentioned Jellyfin in the title because in an effort to see if it was just Plex being annoying, I spun up a Jellyfin container, only to find that Jellyfin also doesn’t work.

Any ideas? I’m offering 10,000 years of incredible luck to anyone that can help me out…

tl;dr I cannot for the life of me get Plex (or Jellyfin) to work via a Pangolin Newt tunnel. All other services served the same way appear to work great.

Edit: So, I figure this has got to be something between Plex, one or more Docker bridge networks, and the Newt Tunnel network (newtwork? nah…). I should have mentioned earlier but I am pretty green with all of this, but I really did want to get my hands dirty. I really only have a surface level understanding of these virtual bridge networks that Docker uses…

I’m realizing in doing some digging with docker network inspect, even Overseerr creates a bridge network. I thought I tried using Plex in bridge mode, but that didn’t seem to work.

Edit Edit: Solved! I looked to Plex’s logs and found that it was rejecting (401) requests from the Newt container bridge. All I had to do was go to Plex’s network settings and allow that subnet, like so:

vE40s7gStWZN7zB.png

My https://plex.domain.tld/ worked instantly. Shoutout to ineedmana for telling me to look in the logs. Always read the logs!

Good morning/evening my selfhosting friends,

I’m kind of a noob, so hopefully I can articulate what I’d like to accomplish well. I am currently in the process of overhauling my entire homelab, which has involved me setting up a VPS as a proxy/tunnel for remotely connecting to/exposing services on my LAN due to my ISP having me behind CGNAT.

Currently, I have a subdomain (provided via Namecheap) pointed at the static IP of the VPS. With this, I can ssh into my server with ssh root@vps.domain.tld which is what I want. Now, I seem to have landed on Pangolin for accomplishing the aforementioned proxy. However, when installing it, I’m stumped by the first few questions: Pangolin wants me to input my domain.tld, followed by pangolin.domain.tld for Pangolin specifically.

Reading the docs, they then want me to either create an A Record for a wildcard domain at my VPS’ IP, or create a root domain record aimed at the IP. My question is, how do I keep the vps.domain.tld while also allowing for pangolin.domain.tld to be valid at the same IP? I know I can create SRV Records, but I am unsure how Pangolin will handle that with the multiple TCP/UDP ports it needs open. I’ll also want to access it via HTTPS obviously, which may add some complexity.

I hope this makes sense, sorry if anything is unclear or if the solution is obvious.

  • I don’t mean to add to the discourse here or to keep giving you hypotheticals but, while learning to self host is fun and cool, you really do not want this thing on public Internet. Even if you can delete files to prevent uncouth things, what if someone uploads something while you’re asleep, or away from your computer? Do you have others monitoring the instance to take down CSAM or other illegal material? What if someone uploads malware and it executes on your machine? If you must leave it exposed, you should allow only family and friends to access via a strongly passworded account(I think that is configurable with copy party).

    If you really want to expose services, try a media server like Plex or Jellyfin. You don’t want strangers to upload things to your machines.