Troubleshooting on homelab

Git Push Authentication

Fri, 01 May 2026 00:00:00 +0000

Git Push Authentication#

What Was Established#

GitHub deprecated password authentication for Git over HTTPS. Even if passwords worked previously, they are now rejected with password not supported.
Personal Access Tokens (PAT) or SSH keys are required for authentication.
403 Permission Denied errors typically indicate stale cached credentials or insufficient token scopes.

Key Decisions#

Use Personal Access Tokens (PAT) for HTTPS Git operations.
Classic tokens require the repo scope for private repositories.
Fine-grained tokens require Contents (Read and write) and Metadata (Read) permissions, explicitly scoped to the target repository.

Current Configuration#

GitHub Username: NK-Iluvatar
Target Repository: MBTADashboard
Remote URL: https://github.com/NK-Iluvatar/MBTADashboard.git

Historical Notes#

Password Deprecation: GitHub enforced its 2021 policy change retroactively, blocking account passwords for Git operations over HTTPS.
403 Troubleshooting: Resolved by clearing cached credentials (git credential reject or OS credential manager) and verifying token scopes (repo for classic, Contents for fine-grained).
Token Testing: Verified token validity using curl -H "Authorization: token TOKEN" https://api.github.com/user.

Open Questions#

None.

Git Pull Strategies
Homelab Dashboard

Sources#

DeepSeek conversation (2026-02-18) regarding MBTADashboard push failures and PAT configuration.

Git Push Authentication

Fri, 01 May 2026 00:00:00 +0000

Git Push Authentication#

What Was Established#

Patterns for resolving Git push authentication issues and handling divergent branches when working across multiple machines.

Key Decisions#

Multi-machine workflow: Always git pull before starting work; commit and push when done.
Divergent branch resolution: When local and remote have diverged, use git pull --no-rebase (merge) for safety or git fetch origin && git reset --hard origin/main to discard local commits for remote-only state.

Resolving Divergent Branches#

Symptom#

hint: You have divergent branches and need to specify how to reconcile them.
fatal: Need to specify how to reconcile divergent branches.

Option 1: Merge (preserves both histories)#

git pull --no-rebase
# Or set as default:
git config pull.rebase false

Option 2: Rebase (local commits on top of remote)#

git pull --rebase
# Or set as default:
git config pull.rebase true

Option 3: Discard local, use remote only#

git fetch origin
git reset --hard origin/main

Option 4: Fast-forward only (fails if diverged)#

git pull --ff-only

Multi-Machine Workflow#

When working from multiple machines on the same repo:

Hugo Deployment to Cloudflare Pages - Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Patterns for resolving missing assets (favicons, CSS, styling) and build failures when deploying Hugo-generated static sites to Cloudflare Pages.

Key Decisions#

Build Configuration: Set build command to hugo, output directory to public, and explicitly match the local Hugo version in Cloudflare Pages settings.
Static Asset Placement: Ensure all static files (e.g., favicon.ico, CSS) reside in the static/ directory root or theme-specific static folders.
Rebuild Enforcement: Use hugo --cleanDestinationDir or manually remove the public/ directory to force Hugo to regenerate all assets and detect changes.
Cache Management: Clear both Cloudflare Pages deployment cache and browser cache to prevent stale asset delivery.
Verification Workflow: Validate locally via hugo server, inspect the generated public/ directory, review Cloudflare deployment logs, and confirm full Git commits.

Current Configuration#

Build Command: hugo
Output Directory: public
Static Directory: static/
Config File: config.toml / config.yaml (verify baseURL matches target domain)

Obsidian Integration for Hugo Date Format#

Hugo expects ISO 8601 dates with timezone offset: 2025-11-22T23:11:12-05:00

KVM Input Switch Sleep Issues

Fri, 01 May 2026 00:00:00 +0000

KVM Input Switch Sleep Issues#

What Was Established#

Switching inputs on a KVM switch can trigger connected PCs to enter sleep mode and fail to wake up. This is typically caused by EDID handshake interruptions or power management settings reacting to display signal loss when the KVM switches away from a connected machine.

Key Decisions & Troubleshooting Steps#

Hardware Model: Inland Dual 4K Display KVM Switch/Dock.
EDID Emulation: The most critical fix. Ensure the KVM is configured for EDID emulation (often via dip switches or firmware settings) to maintain a persistent display handshake and prevent the host OS from detecting a disconnected monitor.
Firmware Updates: Check manufacturer resources (e.g., Micro Center for Inland) for firmware updates to improve display handshake compatibility.
Windows Power Management:
- Set ‘Screen’ and ‘Sleep’ to ‘Never’ in Power & Sleep settings.
- Adjust NVIDIA Control Panel power management to ‘Prefer Maximum Performance’.
- Use Group Policy (gpedit.msc) to disable video/display power saving templates.
Linux Mint Power Management:
- Configure /etc/X11/xorg.conf to disable blank/standby/suspend/off times (ServerFlags section).
- Add xset s off and xset -dpms to startup applications.
- Modify GRUB cmdline (/etc/default/grub) with video=vesafb:off video=eefb:off drm_kms_helper.edid_firmware=edid/1920x1080.bin.
Hardware Checks: Use high-quality/shorter HDMI/DisplayPort cables, ensure direct monitor connections to KVM outputs, and utilize the KVM’s built-in USB hub for peripherals.
Workaround: Manual wake via brief power button press or keyboard input if automatic wake fails due to lost display signal.

Historical Notes#

Conversation date: 2025-11-29.
Specific to Inland Dual 4K KVM dock behavior.
EDID emulation is consistently the primary resolution for this class of KVM-induced sleep issues.

Open Questions#

Does the specific Inland dock model have a known firmware revision that fully resolves this behavior?
Are external EDID emulators required if built-in emulation remains insufficient?

wiki/hardware/monitor-standards.md
wiki/infrastructure/gpu-passthrough-lxc.md

Sources#

ingested/chats/122-KVM Input Switch Causes PC Sleep Issue.md

Mobile Hotspot & Proton VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Mobile Hotspot & Proton VPN Troubleshooting#

What Was Established#

A PC connected to a mobile hotspot will always display a local/private IP address (e.g., 192.168.43.x) to communicate with the phone acting as the gateway/router.
Enabling Proton VPN on the mobile device does not automatically extend the encrypted tunnel to connected hotspot devices by default. This is due to app-level vs. system-level routing, separate network interfaces, and carrier/OS restrictions.
Public IP verification and DNS leak tests are required to confirm whether hotspot traffic is actually being routed through the VPN tunnel.

Key Decisions#

Local IP vs Public IP: Local IPs are expected and required for LAN communication; privacy and security are determined by the public IP and DNS resolution, not the local address.
VPN Extension Methods:
- Enable “Always-on VPN” and “VPN passthrough” in the phone’s hotspot/tethering settings.
- Install Proton VPN directly on the PC for guaranteed tunneling, kill switch functionality, and split tunneling control.
- Use USB tethering instead of Wi-Fi hotspot if Wi-Fi passthrough fails or is blocked by the carrier.
Order of Operations: Disabling and re-enabling the hotspot after establishing the VPN connection can force the routing table to update and apply the tunnel correctly.

Current Configuration#

N/A (General networking troubleshooting pattern applicable to remote management of homelab infrastructure like Isengard (192.168.1.69) or Legolas (192.168.1.45) via mobile data).

Historical Notes#

Conversation dated 2025-12-13.
Proton VPN mobile app behavior varies significantly by OS (iOS/Android) and mobile carrier; some devices natively block VPN over hotspot.
This pattern is relevant for remote homelab administration or travel scenarios where mobile data serves as the primary internet source.

Open Questions#

Does the specific mobile carrier or OS version in use support native VPN passthrough for hotspots without third-party apps?
Are there specific Proton VPN mobile app settings that consistently bypass carrier restrictions for tethering?

Sources#

ingested/chats/130-PC Local IP While Hotspot with VPN.md
DeepSeek conversation: PC Local IP While Hotspot with VPN (2025-12-13)

PLA Filament Troubleshooting & Calibration

Fri, 01 May 2026 00:00:00 +0000

PLA Filament Troubleshooting & Calibration#

What Was Established#

Switching PLA filament colors can cause functional failures even with identical models due to subtle differences in pigment, viscosity, shrinkage rates, and surface finish.
Whistle functionality is highly sensitive to airway geometry, fipple edge sharpness, and internal surface smoothness.
Top surface ironing in Bambu Studio can cause “dimple” pits due to over-melting, insufficient underlying support, or incorrect flow/speed ratios.

Key Decisions#

Functional Failure (Color Switch)#

Dimensional Accuracy: Different pigments cause varying shrinkage. A 0.1-0.2mm variance in airway width or fipple can kill sound.
- Fix: Run a Temperature Tower and Flow Rate/Extrusion Multiplier Calibration for the new color.
Surface Finish & Friction: Viscosity differences affect interior surface smoothness.
- Fix: Lower print temperature by 5-10°C to reduce glossiness and sharpen the fipple edge. Max cooling fan (100%) during ironing/printing.
Moisture: New filament rolls may absorb ambient moisture, causing bubbling and inconsistent extrusion.
- Fix: Dry filament at 45-50°C for 4-6 hours.
Retraction/Oozing: Viscosity changes can cause stringing inside the airway.
- Fix: Increase retraction distance by 0.5-1mm or increase speed. Enable “Retract on Layer Change”.
Post-Processing: Critical for fipple edges.
- Fix: Use folded printer paper or a precision knife to manually deburr and sharpen the internal fipple edge. Probe airway with thin filament to check for obstructions.

Surface Pitting (Ironing)#

Over-Ironing: Excessive ironing flow or low nozzle height displaces molten plastic, creating waves that solidify into pits.
- Fix: Reduce Ironing Flow by half (e.g., 10% -> 5%). Increase Ironing Speed by 20-30%. Adjust Ironing Line Spacing wider (e.g., 0.1mm -> 0.15mm).
Insufficient Support: Too few top layers or low infill density causes the top surface to deflect into the infill pattern.
- Fix: Increase Top Layers to 4-6. Increase Infill Density to 20-25% using Gyroid or Rectilinear patterns.
Temperature Sensitivity: Blue PLA may be more heat-sensitive.
- Fix: Set Ironing Temperature 5-10°C lower than normal print temp. Ensure 100% fan cooling during the ironing pass.

Alternative Approach (Skip Ironing)#

Ironing is aesthetic and unnecessary for functional parts like whistle bodies.
Fix: Rely on standard top layer settings: Top Layer Flow at 105-110%, smaller Top Layer Line Width (e.g., 0.3mm on 0.4mm nozzle), and sufficient Infill Overlap (15-20%).

Current Configuration#

Baseline Ironing Settings (Clean Ironing):
- Top Layers: 5
- Infill Density: 25% (Gyroid)
- Ironing: Enabled
- Ironing Flow: 5%
- Ironing Speed: 100 mm/s (or 1.5x normal top layer speed)
- Ironing Temperature: -5°C from base print temp
- Fan during Ironing: 100%
Standard Top Layer Fallback:
- Top Layer Flow: 105-110%
- Top Layer Line Width: 0.3mm (on 0.4mm nozzle)
- Infill Overlap: 15-20%

Historical Notes#

Conversation date: 2026-02-01.
Specific to Bambu Studio slicer settings and PLA filament behavior.
No specific hardware or software versions mentioned beyond standard PLA and Bambu Studio ironing features.
No known changes to filament manufacturing standards or slicer algorithms since this date.

Open Questions#

Does the specific blue PLA brand have known shrinkage characteristics compared to the green PLA?
Are there slicer profiles or G-code modifiers specifically tuned for whistle geometries?

Bambu Studio Layer G-code

Sources#

ingested/chats/163-Troubleshooting Blue PLA 3D Printed Whistles.md
Historical DeepSeek conversation (2026-02-01) on 3D printed whistle troubleshooting.

Proxy Management & Cloudflare Tunnels

Fri, 01 May 2026 00:00:00 +0000

Proxy Management & Cloudflare Tunnels#

What Was Established#

There are multiple layers of proxying available in the homelab, ranging from edge protection (Cloudflare) to local routing (OPNsense/Nginx Proxy Manager).

Nginx Proxy Manager (NPM) Troubleshooting#

Redirect Loops & Timeouts: Often caused by misconfigured upstream servers or aggressive timeout settings in NPM’s web UI. Resolving a redirect loop may expose underlying connectivity issues that manifest as timeouts.
Docker Compose Pattern: NPM is deployed with network_mode: host to bind directly to host ports (80, 443, 81), bypassing Docker’s NAT for direct host network access.
Verification Steps:
1. Check container health: docker ps | grep nginx-proxy-manager (ensure healthy status).
2. Verify port bindings: sudo netstat -tulpn | grep :80 / :443 (requires net-tools package).
3. Inspect NPM Web UI: Access at http://<host-ip>:81 to review Proxy Host settings, specifically timeout values and upstream server addresses.
Port Conflicts: Use netstat to identify which container owns a specific port (e.g., docker-proxy vs nginx: master). In this setup, port 8000 was observed bound to docker-proxy, indicating another service in the compose stack.
Co-located Services: The same Docker Compose stack hosts cloudflare-ddns (for dynamic IP updates) and netbird (for mesh networking), requiring careful port management to avoid conflicts.

Key Decisions#

Use network_mode: host for NPM to simplify port mapping and ensure direct access to host network interfaces.
Rely on net-tools (netstat) for quick port binding verification in host-networked Docker containers.

Current Configuration#

Docker Host: iluvatar@proxy (192.168.1.208)
NPM Web UI: http://192.168.1.208:81
Ports: 80 (HTTP), 443 (HTTPS), 81 (NPM Admin UI)

Historical Notes#

Troubleshooting session from 2025-11-17 resolved a redirect loop that subsequently turned into a timeout issue.
net-tools installation was required to diagnose port bindings on the host.

Open Questions#

Specific timeout values configured in NPM for upstream services.
Whether netbird or cloudflare-ddns requires dedicated port exposure or can share the host network.

Uptime Kuma - Configuration & Integrations

Servarr - Media Automation Stack

Fri, 01 May 2026 00:00:00 +0000

Servarr - Media Automation Stack#

Overview#

Servarr is a full VM at 192.168.1.112 (hostname: servarr) running a Docker Compose media automation stack. All services depend on a NAS mount at /data for media storage. Download clients (qbittorrent, nzbget) and indexer (prowlarr) route through a Gluetun VPN container via network_mode: service:gluetun.

Note: This VM is distinct from Varda (192.168.1.131), which is a separate web server hosting ilmare.nbkelley.com.

VM Specs#

Detail	Value
Hostname	`servarr`
IP	`192.168.1.112`
OS	Ubuntu 24.04.4 LTS (Noble)
Kernel	6.8.0-107-generic
CPU	QEMU Virtual CPU, 4 vCPUs
RAM	7.8 GB
Disk	63 GB root (`/dev/sda2` ext4, 38% used)
Hypervisor	Proxmox (Minas Tirith)

Container Inventory#

Servarr Stack (`/docker/servarr/compose.yaml`)#

Network: servarrnetwork (172.39.0.0/24)

Servarr Stack - Gluetun VPN Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

Servarr Stack - Gluetun VPN Troubleshooting#

Historical note: This session was conducted on a machine at 192.168.1.30 (hostname possibly “Varda” at the time, directory ~/home/nbkelley/docker/servarr). The current production Servarr stack lives on the servarr VM at 192.168.1.112, directory /docker/servarr/. See Servarr - Media Automation Stack for current configuration. The troubleshooting patterns documented here remain applicable.

What Was Established#

This session documents the deployment and troubleshooting of the Servarr media automation stack (Sonarr, Prowlarr, qBittorrent) behind a Gluetun VPN container. The stack relies on network_mode: service:gluetun to route all container traffic through AirVPN.

SSH Host Key Management & Troubleshooting

Fri, 01 May 2026 00:00:00 +0000

SSH Host Key Management & Troubleshooting#

What Was Established#

Standard procedures for resolving SSH REMOTE HOST IDENTIFICATION HAS CHANGED warnings, which occur when a host’s SSH fingerprint differs from the locally stored known_hosts entry. This typically happens after a server reinstall, OS upgrade, or SSH key regeneration.

Key Decisions & Commands#

Verify Legitimacy: Always confirm with a system administrator or check server logs if a key change is unexpected, as it could indicate a man-in-the-middle attack.
Remove Stale Keys: Use ssh-keygen -R <hostname> to safely remove the outdated entry from ~/.ssh/known_hosts.
Targeted Removal: If the error specifies a line number (e.g., line 9), you can remove it via sed -i '' '9d' ~/.ssh/known_hosts or manually edit the file.
Pre-populate Keys: In managed environments, use ssh-keyscan <host> >> ~/.ssh/known_hosts to automate key acceptance.
Security Best Practice: Prefer certificate-based authentication in sensitive environments to bypass host key checking entirely.

Current Configuration#

Host Encountered: proxy (192.168.1.222, Nginx Proxy Manager)
User Context: Commands executed from macOS (NK---Galadriel) as user natekelley.
Fingerprint Example: SHA256:k5j8V356rpQXapznIs12MeBEWHfZYwfeicXdNNWFyOI (ED25519)

Historical Notes#

Initial troubleshooting documented on 2025-11-17. The proxy host likely had its underlying VM/container rebuilt or its SSH configuration reset, triggering the warning.

Open Questions#

Should SSH host keys be version-controlled or managed via a configuration management tool (e.g., Ansible) to prevent future mismatches?

Sources#

ingested/chats/111-Check and Install Git, Go, Dart Sass on Ubuntu.md
ingested/chats/104-SSH Host Key Change Warning and Fix.md
Historical DeepSeek conversation: SSH Host Key Change Warning and Fix (2025-11-17)

OPNsense Interface Reassignment & NIC Troubleshooting

Mon, 27 Apr 2026 00:00:00 +0000

OPNsense Interface Reassignment & NIC Troubleshooting#

What Was Established#

Procedures for reassigning WAN/LAN interfaces via the OPNsense console following a system upgrade, and troubleshooting connectivity loss after a physical NIC replacement.

Key Decisions#

Console-Based Reassignment: Use the OPNsense console menu (1. Assign Interfaces) to map physical ports to WAN/LAN roles.
Network-Only Reset: If configuration is lost, use 2. Reset to factory defaults and select “Reset only the network configuration” to preserve other settings.
Manual Config Edit: Fallback to vi /conf/config.xml to manually adjust <interfaces> tags (<wan>, <lan>) if the menu fails.
NIC Troubleshooting Workflow: Verify driver recognition (vmstat -i), link status (ifconfig), and system logs (dmesg). Check NAT/Outbound and LAN firewall rules. Isolate hardware issues by reverting to the original NIC.

Current Configuration#

Gateway: UCG Express “Olorín” (OPNsense) at 192.168.1.1.
VLANs: Gandalf (192.168.1.x), Mithrandir (192.168.2.x), Tharkûn (192.168.3.x), Rivendell (192.168.4.x).
Switch: Netgear MS308E (trunk/access VLANs managed via OPNsense).

Historical Notes#

Procedures documented for OPNsense upgrades where interface assignments reset.
Troubleshooting steps refined for scenarios involving physical NIC swaps (e.g., 2.5GbE to 1GbE) causing interface loss.
Note: Driver support (Intel igb/em, Realtek) and firmware updates may be required for newer NICs.

Open Questions#

Specific driver requirements for the current UCG Express “Olorín” gateway NICs.
Automation of interface reassignment to prevent manual console steps during future upgrades.

Sources#

ingested/chats/034-Reassign WAN and LAN on OPNsense Post-Upgrade.md
Historical DeepSeek conversation on OPNsense console interface reassignment and NIC troubleshooting.

Windows VM Installation Troubleshooting

Thu, 23 Apr 2026 00:00:00 +0000

Windows VM Installation Troubleshooting#

What Was Established#

Troubleshooting guide for Windows installation when the local disk does not appear in the partitioning screen during setup.

Key Troubleshooting Steps#

Check disk detection in BIOS/UEFI — If the disk doesn’t appear in BIOS, it’s a hardware issue (loose cable, faulty drive, wrong SATA port).
Load storage drivers — Modern NVMe/RAID controllers may need drivers loaded during setup via Shift + F10 → “Load Driver”.

VS Code Live Server Path Configuration

Mon, 31 Mar 2025 00:00:00 +0000

VS Code Live Server Path Configuration#

What Was Established#

Resolved the “Cannot GET /page-name” error in VS Code Live Server by implementing a standardized project directory structure and correct relative pathing. The core fix involves ensuring the server root is set to the project root and using ../ to traverse up from subdirectories.

Key Decisions#

Project Rooting: Always open the top-level project folder in VS Code rather than individual subfolders (like html/). This allows Live Server to correctly resolve paths relative to the project root.
Directory Separation: Adopted a structured hierarchy to separate assets, logic, and presentation.

Current Configuration#

Project Structure#

project-root/
├── Assets/
│   ├── icons/
│   └── images/
├── html/
│   ├── index.html
│   ├── about.html
│   └── contact.html
├── scripts/
│   └── main.js
└── Styles/
    └── style.css

Pathing Rules (when working inside `html/`)#

When files are located within the html/ subdirectory, all links to external directories must use the ../ prefix to exit the html/ folder first.

Proxmox Network Troubleshooting

Tue, 25 Mar 2025 00:00:00 +0000

Proxmox Network Troubleshooting#

What Was Established#

Troubleshooting steps for resolving connectivity loss to Proxmox nodes, specifically addressing IP conflicts and subnet mismatches.

Key Decisions#

Static IP Reservation: Proxmox nodes should always have a static IP (e.g., 192.168.0.69) that is excluded from the OPNsense DHCP pool.

Current Configuration#

Troubleshooting Workflow#

Verify Connectivity: ping 192.168.0.69.

Check Local Config: Log in via console and verify /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.0.69/24
    gateway 192.168.0.1
    bridge-ports enp3s0

Check for IP Conflicts: Ensure no other device (via DHCP) has been assigned 192.168.0.69.
ARP Cache: Clear local ARP cache if IP conflicts are suspected: arp -d 192.168.0.69.

Historical Notes#

Identified an issue where a DHCP client was assigned 192.168.0.69, conflicting with the Proxmox static IP.

Troubleshooting DeepSeek Language Switching

Tue, 25 Mar 2025 00:00:00 +0000

Troubleshooting DeepSeek Language Switching#

What Was Established#

Local DeepSeek models may intermittently switch from English to Chinese mid-response. This is typically caused by training bias (heavy Chinese dataset influence), loss of context during long conversations, or mixed-language input prompts.

Key Decisions#

To maintain English-only responses, the following parameters and prompting strategies should be applied:

Explicit Instruction: Always include a system-level or initial prompt instruction to respond exclusively in English.
Temperature Control: Use lower temperature settings (e.g., 0.3) to make the model more deterministic and less likely to drift.
Repetition Penalty: Implement a repetition_penalty (e.g., 1.2) to discourage the model from falling into repetitive patterns that might trigger language switching.

Current Configuration#

System Message Pattern#

When using APIs or local inference engines that support system roles:

Troubleshooting Network Interface Changes

Sun, 23 Mar 2025 00:00:00 +0000

Troubleshooting Network Interface Changes#

What Was Established#

When replacing a physical Network Interface Card (NIC)—for example, swapping a 2.5GbE card for a 1GbE card—the system will lose connectivity if the software configuration still references the old interface name.

Key Decisions#

Connectivity loss after a hardware swap is usually due to a mismatch in the bridge-ports setting within the network configuration. The new NIC will likely have a different kernel interface name (e.g., changing from enp0s1 to enp0s2).

Troubleshooting on homelab

Git Push Authentication

Git Push Authentication#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Git Push Authentication

Git Push Authentication#

What Was Established#

Key Decisions#

Resolving Divergent Branches#

Symptom#

Option 1: Merge (preserves both histories)#

Option 2: Rebase (local commits on top of remote)#

Option 3: Discard local, use remote only#

Option 4: Fast-forward only (fails if diverged)#

Multi-Machine Workflow#

Hugo Deployment to Cloudflare Pages - Troubleshooting

Hugo Deployment to Cloudflare Pages - Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Obsidian Integration for Hugo Date Format#

KVM Input Switch Sleep Issues

KVM Input Switch Sleep Issues#

What Was Established#

Key Decisions & Troubleshooting Steps#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Mobile Hotspot & Proton VPN Troubleshooting

Mobile Hotspot & Proton VPN Troubleshooting#

What Was Established#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

PLA Filament Troubleshooting & Calibration

PLA Filament Troubleshooting & Calibration#

What Was Established#

Key Decisions#

Functional Failure (Color Switch)#

Surface Pitting (Ironing)#

Alternative Approach (Skip Ironing)#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Sources#

Proxy Management & Cloudflare Tunnels

Proxy Management & Cloudflare Tunnels#

What Was Established#

Nginx Proxy Manager (NPM) Troubleshooting#

Key Decisions#

Current Configuration#

Historical Notes#

Open Questions#

Related Pages#

Servarr - Media Automation Stack

Servarr - Media Automation Stack#

Overview#

VM Specs#

Container Inventory#

Servarr Stack (/docker/servarr/compose.yaml)#

Servarr Stack - Gluetun VPN Troubleshooting

Servarr Stack - Gluetun VPN Troubleshooting#

What Was Established#

SSH Host Key Management & Troubleshooting

SSH Host Key Management & Troubleshooting#

What Was Established#

Key Decisions & Commands#

Current Configuration#

Historical Notes#

Servarr Stack (`/docker/servarr/compose.yaml`)#

Pathing Rules (when working inside `html/`)#