I’m using the standard Digital Ocean Droplet prebuilt; however that was built. I do not know exactly how it as configured as I didn’t build/install it, it’s the stock configuration supplied with the droplet.
No matter what I put in /var/www/html Caddy just serves a blank page.
Also, I want to run it on an ip address only (no DNS name), so my Caddyfile looks like this with no DNS name:
:80
root * /var/www/html
file_server
The problem I’m having:
Caddy serves only a blank page, not the contents of the root directory.
What I already tried:
putting different files in the root directory e.g. index.html, test.html, test.txt… etc.
reloading Caddy
disabling ufw
pointing the root to a different directory
rebooting the entire droplet
Please put ``` on the lines before and after your config to use code formatting when posting it in the forums, it preserves whitespace and makes it easier to read.
Also, please fill out the entire issue template, you didn’t provide any logs or an explanation of what behaviour you’re seeing instead of what you expect.
Your config you posted has /var/www/htm but you say you’re putting files in /var/www/html. Is that an oversight?
This should work with a default page of index.html with no problems at all.
I just tried it here just to make sure the config works on ip address on Ubuntu 18.04. If you add browse to the file_server as above then don’t add any files in the folder /var/www/html at all and you should get a Caddy Directory Browser appear.
Check your log file in /var/log/syslog and output the file here.
I’ve reviewed our scripts, and we set the correct ownership to the directory /var/www/html. See here
and here
My guess of what happened is that the newly created/uploaded files were created/uploaded using the root user, so the new files get owned by root which prohibits the caddy user from accessing them. I honestly don’t have any good idea yet around the OS giving permissions/ownership of the new files to the user who created them. I also think the OS is doing the right thing here (i.e. the user who creates a file definitely owns the file), so not sure what workaround will be good in this scenario.
If any of you has a good idea to avoid the ownership issue while not circumventing security, we’re all ears.
Does ubuntu have groups? make a user in the group caddy… Caddy:webworker or something like that. Give that user terminal and SFTP access and add files that way. put a step in your script that asks the script/droplet user to add a password and set up the user account and SSH/SFTP keys… put a blurb in the script for the user to know that if they add files with the root account, then they need to chown -R the root folder.
The droplet user shouldn’t be doing data work with the root account anyway… just sloppy and asking for cowboy errors, right?
Thank you for the suggestion, but that wouldn’t work. DigitalOcean’s marketplace images are clean VM images that should not have any non-system user accounts. All of DO’s images come with only root user available for the end-user. The end-user is, in turn, responsible for managing their own unix users/groups. We do use Ubuntu’s groups (Linux’s, in fact) by creating a designated group called caddy which is native to the caddy system user. We also add the caddy system user to the www-data group to avoid surprising users who are expecting the www-data group to just work for file serving.
DO’s images assume the end-user is versed in the *inx-flavor of the image to understand they need to create themselves a user besides root, mind the file ownership, and keep an eye on files permissions.
I just went through setting up a new DO droplet with Caddy installed on it yesterday (for the new Caddy website updates, in fact). I uploaded files using SFTP and after they were uploaded, they were owned by root but were world-readable and the site worked just fine, with caddy running as the caddy user.
it was root:root, and changing to caddy:caddy fixed it.
I’ll start using rsync for copies, so that I can specify proper user and group.
So that’s clearly user error, and my obliviousness is clearly not really Caddy (or devs) problem, nor should it be. Thank you for the assistance.
I would suggest/ask, though, that a note that /var/www/html is not owned by Caddy be put in the “Getting Started” tutorial that comes with the droplet. Or a note that one should change permissions on it after editing the Caddyfile. Or perhaps simply leave out the instruction to switch the root directory to /var/www/html altogether. As following the instructions exactly as written does literally break the ability to serve pages unless one also chowns the directory.