403 Error With Caddy

[Nebula-0-System]

Description

when setting up Sheaf i'm getting a 403 error forbidden with caddy.

i followed the backend and frontend sections of the guide, then ran docker compose up -d, and i'm getting 403 errors with caddy. the backend API shows only detail: "Not Found" on the page.

my first thought was the port was the issue, then i thought about the trusted proxies and corrected that, then i thought it was carry but i double checked the caddyfile and restarted the service twice. i thought maybe docker compose down and docker compose up -d would fix it, then i thought "ok since it's a file server, and Caddy's a root service, that means root needs to read the files" and checked that but they have read perms for user, group, and others.

Sheaf has a lot of stuff and security built in (it's impressive) and i'm a bit lost on what's going wrong here since there's so much.

Steps to reproduce

near as i can tell, this should reproduce it:
1: git clone the repo
2: copy env example to .env
3: generate keys & adjust other settings (mode, admin emails, port, etc)
4: follow frontend instructions in documentation

Expected behaviour

get a UI of some sort, or a setup screen, something other than errors.

Sheaf version / commit

8db460d

Deployment

Self-hosted (Docker Compose)

Relevant logs

npm install

added 2 packages, and audited 445 packages in 797ms

155 packages are looking for funding
  run `npm fund` for details

found 0 vulnerabilities


npm run build

> web@0.1.0 build
> tsc -b && vite build && node scripts/build-manifest.mjs

vite v7.3.3 building client environment for production...
✓ 4145 modules transformed.
dist/index.html                               2.23 kB │ gzip:   0.88 kB
dist/assets/github.min-U4im7YUz.css           1.06 kB │ gzip:   0.45 kB
dist/assets/github-dark.min-DOOs4slz.css      1.07 kB │ gzip:   0.45 kB
dist/assets/index-oiPfCU2X.css               99.28 kB │ gzip:  15.84 kB
dist/assets/bio-editor-d1LJ8zRz.js          359.00 kB │ gzip: 110.71 kB
dist/assets/index-CBR1yRfR.js             1,431.28 kB │ gzip: 419.08 kB

(!) Some chunks are larger than 500 kB after minification. Consider:
- Using dynamic import() to code-split the application
- Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks
- Adjust chunk size limit for this warning via build.chunkSizeWarningLimit.
✓ built in 4.37s

Environment

uname -a Linux The-Abyss-Primordial-Eldritch-Horror-Cradle-Of-The-Unknown 6.8.0-111-generic #111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux
OS: Linux Mint

node -v v24.15.0

npm -v 11.12.1

[SiteRelEnby]

ehehehehe, nice kernel name.

Will pick this up tonight. Not used Caddy much but makes sense to have as an example in deployment notes.

[Nebula-0-System]

thank you! all of my machines have some grandiloquent hostname. i have the full character hostname, i'm going to use the full hostname lol.

that said, got lots of time to kill this evening so i'm free to help debug and test and such

(P.S.: you're an absolute vibe)

[SiteRelEnby]

Had a go at reproducing it, and wasn't able to with the example Caddyfile in SELFHOSTING.md. Have to admit we're not that familiar with Caddy specifically, the public beta instance is using an existing nginx+letsencrypt stack we had, but when we brought it up as a test it worked. Can you share a sanitized version of your Caddy config?

(P.S.: you're an absolute vibe)

Thanks. Honestly took a lot of introspection and iteration.

[Nebula-0-System]

Alixian (previous comments were Aleena): here's what we have. got ddclient running for dynamic dns, and use porkbun's stuff for the certs n such (Caddy is an absolute legend, S tier software).

# The Caddyfile is an easy way to configure your Caddy web server.
#
# Unless the file starts with a global options block, the first
# uncommented line is always the address of your site.
#
# To use your own domain name (with automatic HTTPS), first make
# sure your domain's A/AAAA DNS records are properly pointed to
# this machine's public IP, then replace ":80" below with your
# domain name.

# global settings
{
	acme_dns porkbun {
		api_key {env.PORKBUN_API_KEY}
		api_secret_key {env.PORKBUN_API_SECRET_KEY}
	}
admin off
}

(other sites here, below is only temporarily commented out to avoid access until it's properly setup)

# subdomain.nebula-system.com {
#	handle /v1/* {
#		reverse_proxy localhost:19851
#	}
#	handle {
#		root * /home/nebula/services/sheaf/web/dist
#		try_files /home/nebula/services/sheaf/web/dist/index.html
#		file_server
#	}
#}
# Refer to the Caddy docs for more information:
# https://caddyserver.com/docs/caddyfile

sanitized other sites and subdomain.

UFW doesn't have an opening for Sheaf, but with Caddy that hasn't been necessary for other things, but we haven't tested that yet, especially since it's using loopback in compose file to route Caddy.

Thanks. Honestly took a lot of introspection and iteration.

as an introjected persecutor, turned protector, I get that a lot. personal growth's rough but worth it in the end.

[SiteRelEnby]

Looks like a subtle permissions issue.

Caddy returns a 403 when the user it runs as cannot traverse a parent directory on the way to the static files, even if the files themselves are 0755. On Ubuntu/Mint, the systemd Caddy package runs as the user caddy, and /home/nebula/ is likely 0700 (Mint's adduser default), so caddy gets EACCES on open, and turns that into 403.

Best solution is to use /var/www or similar. If you sudo -u caddy -i you cam test readability of specific file paths, or sudo -u caddy ls /home/nebula/services/sheaf/web/dist/ as a oneliner.

as an introjected persecutor, turned protector, I get that a lot. personal growth's rough but worth it in the end.

Introject protector who's trying to be more than just that here: completely get that. It's been a lot to get my own space in our life, but glad I did.

[Nebula-0-System]

ok if that's the case, wouldn't a symlink made to map /var/www/sheaf to /home/nebula/services/sheaf/web/dist work? then it'd have access to the parent directories, and service files can be kept in the directory for our personal organization (and also git pull updates in lieu of an "All In One" docker image)? just wondering if you can think of reasons to not try that

Introject protector who's trying to be more than just that here: completely get that. It's been a lot to get my own space in our life, but glad I did.

yeah, i'm lucky to have found mine. took a lot of BS internal drama but i got it. i found turning what makes me different into tools was what worked the best.

if you got Signal i'd be interested in being friends and ik the system could use more friends in general, if you are, our username's on our site.

[Nebula-0-System]

Aleena: got it all setup and moved the dist folder's contents to /var/www/sheaf, and just symlinked it the other way around, then edited our caddyfile.

that said, after importing SP data, it keeps popping up with "Not Found" errors, over and over and over in the bottom right, is this something to do with the permissions do you think? i'm not sure why it's doing this. maybe it's just slowly chewing through the import? if so, tbf, our export is 680kb, which for json is a lot, and over 2300 front entries. board messages are also taking forever and largely not loading.

checking dev tools network log, it keeps spitting out 404 on anything related to board messages, when opening member details it 404's, when searching their wall, no dice. maybe it didn't import properly? should i import the file and only import messages?

[SiteRelEnby]

Yeah, a clean import of just messages should help nail it down. If you can also get the container logs from the server itself (docker logs sheaf-app <or whatever it's called in your stack> | grep -E '4[0-9][0-9]') that would be helpful, as you would see what exactly is failing in terms of identifiers of members, if it is as we're guessing the import failing partway in. We've tested on a few synthetic imports but not at significant scale as we used to not really track history much until recently, and there's no substitute for real data, I guess.

Might also think about just adding more detailed server-side logging to imports, maybe move them to an asynchronous job if large histories will end up being a problem, which also preemptively solves potential issues with multiple concurrent imports starving other resources, but also not going to rule out an edge case like misunderstanding something in the data format either until proven otherwise. Really, an opportunity to add more logging to the import process anyway if anything.

[SiteRelEnby]

PS. nice website. Really got to do more with ours.