# Calibre returns 404 when visited through .onion address
**URL:** https://discuss.freedombox.org/t/calibre-returns-404-when-visited-through-onion-address/4256
**Category:** Support
**Created:** [May 24, 2026, 2:54am UTC](https://discuss.freedombox.org/t/calibre-returns-404-when-visited-through-onion-address/4256 "2026-05-24T02:54:05Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@cj-macbeth](https://discuss.freedombox.org/u/cj-macbeth)
#### Post date: [May 24, 2026, 2:54am UTC](https://discuss.freedombox.org/t/calibre-returns-404-when-visited-through-onion-address/4256/1 "2026-05-24T02:54:06Z")
**Problem Description**
Calibre is not accessible via the .onion site (Onion site is available, login and other apps function as expected via onion site)
**Steps to Reproduce Success**
1. Login to FreedomBox via local/IP
2. Launch Calibre
3. There be all the Books
**Steps to Reproduce Error**
1. Login to FreedomBox via .onion/Tor Browser (tried on Debian and Android)
2. Launch Calibre
3. There be no Books, no Books at all : (
Apache autogenerated 404 page
> The requested URL was not found on this server.
**Most Useful Clue Found**
in the file **/etc/apache2/conf-enabled/calibre-freedombox.conf** is the apache **\** block:
```auto
ProxyPass http://127.0.0.1:8844/calibre
Use AuthOpenIDConnect
Use RequireGroup calibre
# Calibre has a bug where an empty value for a HTTP header is treated as
# invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
# out. So, try to pass all the OpenID Connect user information and claims as
# headers that can't have an empty value.
OIDCPassIDTokenAs "serialized"
OIDCPassUserInfoAs "json"
```
when modified, as follows:
```auto
ProxyPass http://127.0.0.1:8844/calibre
#Use AuthOpenIDConnect
#Use RequireGroup calibre
# Calibre has a bug where an empty value for a HTTP header is treated as
# invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
# out. So, try to pass all the OpenID Connect user information and claims as
# headers that can't have an empty value.
OIDCPassIDTokenAs "serialized"
OIDCPassUserInfoAs "json"
```
the calibre app loads (and functions) through the tor browser. Unfortunately, it allows unauthenticated access to all calibre functionality.
In case it helps, disabling one or the other does not work, only both.
I’m not intimately familiar with the inner workings of Apache, so I don’t know what would cause the AuthOpenIDConnect or RequireGroup (separate?) modules to presumably choke on the onion address.
I haven’t been able to identify any pertinent error logs.
In case it also helps, I tried this from an admin account, and, also tried manually adding the user to the calibre user group (though, the admin account _does have access via local/IP_, so I didn’t expect it to matter.
**Information**
> You are running Debian GNU/Linux 13 (trixie) and FreedomBox version 26.8. FreedomBox is up to date.
- x64 server
- apt install freedombox
---
### Author:  [@cj-macbeth](https://discuss.freedombox.org/u/cj-macbeth)
#### Post date: [May 25, 2026, 7:44pm UTC](https://discuss.freedombox.org/t/calibre-returns-404-when-visited-through-onion-address/4256/2 "2026-05-25T19:44:13Z")
**Continued Digging**
Calibre in FreedomBox appears to rely on the mod\_auth\_openidc apache module.
This module appears to refuse to resolve .onion addresses.
**My Digging**
In the **/var/cache/apache2/mod\_auth\_openidc/metadata** directory, where the configurations are for each of the domains freedombox serves (_domain_, _domain_.local, etc), each has both a **.client** and a **.provider** JSON configuration file.
There is no .provider file for the .onion address domain, just a .client file.
I enabled debugging by adding the line:
> LogLevel auth\_openidc:debug
in the **/etc/apache2/conf-enabled/10-freedombox.conf** file (explained in comments of the file, above the Macro block) - which _may_ have enabled the necessary logging in journalctl, or may have done nothing (I didn’t check again with it off to confirm).
After that, I copied the _localhost.provider_ file to a _domain.onion.provider_ file, replaced the domain name occurrances in the file with the onion domain, reloaded the calibre page via torbrowser, and found in the logs (journalctl -xeu apache2) that OpenIDConnect is refusing to resolve .onion addresses, according to RFC 7686.
_Beware if you attempt this yourself, there is a red herring: you must access via HTTPS. Going through HTTP to the .onion address returns a different error, a result of openidc requiring HTTPS._
**So, My New Question Is**
Is there a way around this, so that me and my homies can share books via the calibre library, over tor? Or am I going to be building a custom tool by hand instead?
An acceptable solution, to me, would be to disable authentication for Calibre over the .onion domain, and allow read-only connections (and leave the management of calibre to LAN-only) - or to disable authentication via openidc entirely, and protect access to calibre via a different method such as a separate htaccess or a simple password.
If I attempt this, I will return with the results/solution.
---
### Author:  [@cj-macbeth](https://discuss.freedombox.org/u/cj-macbeth)
#### Post date: [May 25, 2026, 8:42pm UTC](https://discuss.freedombox.org/t/calibre-returns-404-when-visited-through-onion-address/4256/3 "2026-05-25T20:42:41Z")
**Temporary Solution**
I modified the **/etc/apache2/conf-enabled/calibre-freedombox.conf** as follows:
```auto
ProxyPass http://127.0.0.1:8844/calibre
#Use AuthOpenIDConnect
#Use RequireGroup calibre
Include includes/freedombox-auth-ldap.conf
Require valid-user
RequestHeader set X-Remote-User expr=%{REMOTE_USER}
# Calibre has a bug where an empty value for a HTTP header is treated as
# invalid. OIDC_CLAIM_email can be empty and this causes Calibre to error
# out. So, try to pass all the OpenID Connect user information and claims as
# headers that can't have an empty value.
#OIDCPassIDTokenAs "serialized"
#OIDCPassUserInfoAs "json"
```
so now access to calibre requries a valid username and password combination.
I modified the calibre-server command args in the service file **/usr/lib/systemd/system/calibre-server-freedombox.service** to disable write access, which was also successful, though I ended up re-enabling write access after restricting access to the Calibre server to valid users only.
**Now ANY valid user can upload/modify ANY Calibre library. This works for me, but is not an _actual_ solution, since now access is granted differently from how it’s documented. I have no final solution to propse (and I’m done exploring), but between this method and modifying calibre-server’s members and built-in access-control mechanisms, there are various solutions for anyone looking for their own workaround : )**