mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-03-02 22:46:55 -05:00
[Bug]: Server cannot pull author information #2918
Labels
No labels
authentication
awaiting release
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/audiobookshelf-advplyr#2918
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lordofwizard on GitHub (Jul 26, 2025).
What happened?
Running docker compose version of the audiobookshelf
when clicked on "Quick Match" for author the information is not pulled.
Here are the logs.
here is the docker compose file that i am currently using. with v2.26.3 (latest tag at the time of submitting the bug)
What did you expect to happen?
I want it such that it automatilly pulls the author information and show's the author's picture as well as relational metadata
Steps to reproduce the issue
Audiobookshelf version
v2.26.3
How are you running audiobookshelf?
Docker
What OS is your Audiobookshelf server hosted from?
Linux
If the issue is being seen in the UI, what browsers are you seeing the problem on?
Chrome
Logs
Additional Notes
No response
@AIMutant commented on GitHub (Jul 29, 2025):
This happens occasionally on some of my books also. Not everyone but often enough recently. Additionally I found that some of the authors get reset to empty or even to older non-synced data.
@advplyr commented on GitHub (Aug 14, 2025):
Is this resolved for you? If the request is returning a 404 from the server there isn't much we can do about that.
@lordofwizard commented on GitHub (Aug 15, 2025):
@advplyr no, even at the latest version i have the same issue persisting.
@Vito0912 commented on GitHub (Aug 15, 2025):
Please try fetching the URL from inside the container
@lordofwizard commented on GitHub (Aug 16, 2025):
@Vito0912 I did that using curl, i am getting the response of the api back. (i installed curl package in the alpine container of audiobookshelf and ran the command) i am getting response back.
@Hannah-GBS commented on GitHub (Oct 14, 2025):
I just ran into this on the latest version. Did a Quick Match on 10 books, and 8 of them finished with a blank Author field. If I Match manually from the same source the Author field is filled in correctly.
@lordofwizard commented on GitHub (Nov 8, 2025):
It's in a docker container but the issue I am having is a bit hard to put into words (i am beginner and english is not my native lang sorry)
and here's my nginx configuration
@lordofwizard commented on GitHub (Nov 9, 2025):
I fixed it turns out it was a issue with my host.
I am keeping a (AI gen doc) on what I did to solve it.
Date: November 9, 2025
Server: Oracle Cloud Ubuntu Server
Issue: Docker containers unable to establish SSL/TLS connections
🔴 Problem Summary
All Docker containers on the Oracle Ubuntu server were failing to establish SSL/TLS connections to external services (e.g.,
https://www.google.com), while the host system could connect without issues.Error Message
🔍 Root Cause Analysis
The Core Issue
An iptables NAT rule was redirecting ALL port 443 (HTTPS) traffic to port 8080, where an nginx reverse proxy was running with Cloudflare Origin certificates.
bash
What Was Happening
Why Host Connections Worked
The iptables PREROUTING chain primarily affects:
It does NOT typically affect:
This is why
curl https://www.google.comfrom the host worked, but the same command from Docker containers failed.🧪 Diagnostic Process
1. Initial Symptoms
bash
2. Certificate Analysis
Container saw:
Host saw:
3. Network Mode Test
bash
This confirmed the issue was with Docker's network routing, not certificates or DNS.
4. DNS Resolution Check
bash
DNS was working correctly, so the issue was happening after DNS resolution.
5. The Smoking Gun - iptables
bash
This rule was intercepting ALL HTTPS traffic and redirecting it to the nginx reverse proxy.
✅ Solution
The Fix
Remove the blanket port 443 redirect and replace it with a more specific rule that only affects incoming traffic:
bash
What Changed
Before:
After:
enp0s10port 443 → nginx🎯 Key Learnings
1. iptables Chain Ordering Matters
2. Docker Network Isolation
Docker containers don't directly connect to the internet. Their traffic:
3. Certificate Validation
SSL/TLS certificate validation checks:
When nginx intercepted the connection, it presented its own certificate (Cloudflare Origin), which didn't match
www.google.com.4. Testing Methodologies
Best practices for diagnosing Docker network issues:
bash
📋 Server Configuration Context
Network Setup
Docker Configuration
json
Nginx Reverse Proxy
Firewall Rules
Oracle Cloud Security Lists:
UFW:
🚨 Red Herrings Investigated
During troubleshooting, these were investigated but were NOT the cause:
1. ❌ Missing CA Certificates
/etc/ssl/certsinto containers2. ❌ MTU Issues
3. ❌ Docker DNS Configuration
4. ❌ Tailscale Exit Nodes
5. ❌ iptables-nft vs iptables-legacy
6. ❌ Oracle Cloud Network Inspection
🔧 Prevention
To Avoid This Issue in the Future
bash
iptables-saveto backup rulesbash
bridge(default): Isolated network with port mappinghost: Uses host network stack (bypasses iptables PREROUTING)none: No networking📚 Technical References
iptables Chains and Tables
Docker Networking
Docker containers using bridge mode:
SSL/TLS Certificate Validation
🎓 Commands Reference
Diagnostic Commands
bash
Fix Commands
bash
📝 Conclusion
This issue demonstrates the complexity of network routing in containerized environments. A seemingly simple iptables rule intended to redirect incoming HTTPS traffic to a reverse proxy inadvertently broke all outbound HTTPS connections from Docker containers.
Key Takeaway: Always scope iptables rules to specific interfaces and directions to avoid unintended side effects on container networking.
Resolution Time: ~1 hour of troubleshooting
Impact: All Docker containers unable to make HTTPS requests
Severity: High (blocks critical functionality like package updates, API calls, downloads)
Status: ✅ Resolved