I want to use both Web Sharing and FileVault however when I turned on FileVault, my home directory Sites folder came up in the browser as permission denied, even though the Unix permissions were 777, meaning anyone can access it.

How to resolve this?

And by the way where is the toplevel web directory? I am tired of trying to use my ~/Sites directory anyway.

  • 1
    Which OS version (Lion or earlier)? – nohillside Oct 26 '11 at 12:53
  • You are asking two different questions here. Your second question deserves its own post. – Daniel Nov 9 '11 at 3:57

I'm assuming you aren't using Lion, since your description sounds more like FileVault 1 (through Snow Leopard) than FileVault 2 (Lion).

FileVault 1 protects the entire home folder, with encryption when you aren't logged in and permissions when you are. In order to get to files in your Sites folder, the web server process would have to go through your home folder -- since it can't get into your home folder, it also can't get at anything inside it, so the permissions on your Sites folder are irrelevant. (I'd recommend setting the perms on Sites back to 755, though -- 777 is just a bad idea.)

As a result of this, ~/Sites is pretty much useless in FileVault accounts. Same with ~/Public -- normally, it's for sharing files both locally and (if the services are enabled) over AFP and/or SMB, but with FV it's not reachable.

But you do have an alternative: the top level web directory, /Library/WebServer/Documents. Just replace the default files with your own and you should be good to go.

  • Thanks. I guess if I want to make /Library/WebServer/Documents writeable from all accounts without sudo then I'll have to make it 0777. – Wunder Oct 26 '11 at 19:01
  • By the way how does Lion's FileVault differ from SnowLeopard's, which I'm using? – Wunder Oct 26 '11 at 19:17
  • 777 permissions are almost always a mistake; it grants everyone (including guests, the web server itself, etc) full access. If you're an admin, the default permissions already allow you full access, so there's no need to change anything. If you need to allow non-admins to write to the folder, I'd recommend assigning it to a group that includes those you want to grant access to. "staff" is one possibility (it includes all normal user accounts), or you could create your own group (e.g. "webauthors"), and just add the accounts that should have access. – Gordon Davisson Oct 26 '11 at 20:11
  • 2
    As for FileVault vs. FileVault 2: they're completely different. FV encrypts the user's home folder, and decrypts it when they log in (but uses permissions to restrict the home folder even when you're logged in). FV2 encrypts the entire disk (volume, actually), and decrypts it when you boot; once booted, everything is pretty much normal. – Gordon Davisson Oct 26 '11 at 20:14

I had a similar experience with filevault 2 and apache (in El Capitan). I run several virtual host at various ports via a custom .conf file that all point to ~/Sites/xxxxx/. After enabling filevault they all went dead w/ permission denied even though file perms were 755 all the way to ~/Sites.

Then I noticed :80 was still working with the default "It works!" test page so I tried to mimic /Library/WebServer/ by making a /Sites at root alongside /Library and set the perms including ACLs to match /Library, but even that failed. At that point, I began to think the permissions thing wasn't totally related to filesystem permission settings, so I cracked open httpd.conf to find out why :80 was working. That's when I found this line...

    # Controls who can get stuff from this server.
    Require all granted

That was the key. Just add Require all granted to each of your virtual host <Directory> objects and restart Apache.

After that all my stuffed worked and I was able to keep my stuff in ~/Sites.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .