Apache DocumentRoot & Directory Permissions

Folks,
I am trying to use a unique directory for personal web services. So I have modified the following two lines in
/private/etc/httpd/http.conf
#DocumentRoot "/Library/WebServer/Documents"
DocumentRoot "/Users/rsp/Documents/web-maritime-new"
#<Directory "/Library/WebServer/Documents">
<Directory "/Users/rsp/Documents/web-maritime-new">
After restarting the server, I get the following error message when I try to access any of the pages:
"Forbidden
You don't have permission to access /index.htm on this server.
Apache/1.3.33 Server at rspg5.local Port 80"
The permissions on the two directories and the files look the same to me when I use Get Info, or LS.
Does anyone have any ideas?
rich

I am no expert on this, but have you taken heed of the warning in http.conf to not make changes in it based only on the comments it includes but to understand what they mean before making changes? (Presumably, this means reading the manual included with the Apache distribution, or the equivalent.)
Anyway, to my very limited understanding of this, the permissions required for access are not the regular ones of the OS per se, but those controlled by Apache for clients of the server. IOW, when using a browser to access these files/folders, you are doing so as a client of the server in your Mac, not as a local user of the Mac.
I don't think changing the root directory for documents to a location inside a user folder is a good idea, since this would (even if it worked) restrict access to it to that user. If all you want is to modify the index, why not do so in place, by modifying the index.html.en (or whatever language version(s) you want served) to include an alias to the desired Documents folder?
Better still, use the ~/Sites folder for whatever documents you want to serve.

Similar Messages

  • To build the organization's Active Directory permissions are what we need

    To build the organization's Active Directory permissions are what we need

    what is your actual question?  Can you be more specific?
    Santhosh Sivarajan | Houston, TX | www.sivarajan.com
    ITIL,MCITP,MCTS,MCSE (W2K3/W2K/NT4),MCSA(W2K3/W2K/MSG),Network+,CCNA
    Windows Server 2012 Book - Migrating from 2008 to Windows Server 2012
    Blogs: Blogs
    Twitter: Twitter
    LinkedIn: LinkedIn
    Facebook: Facebook
    Microsoft Virtual Academy:
    Microsoft Virtual Academy
    This posting is provided AS IS with no warranties, and confers no rights.

  • [SOLVED] warning: directory permissions differ on var/log/wicd/

    Hi,
    I've seen several posts about this but I couldn't really figure out what's the appropriate action. Well, anyway I get the following error message when doing a pacman -Syu
    warning: directory permissions differ on var/log/wicd/
    filesystem: 1363 package: 755
    Is it a bug? Should I change the filepermission of the directory, and if so to what?
    Last edited by OMGitsUGOD (2009-09-18 10:38:32)

    This is sort of related,
    http://bbs.archlinux.org/viewtopic.php?pid=432588
    or at least thats the post at the end has the same file permisions as I have in /var/log/wicd.
    $ ls -la /var/log/ | grep wicd
    d-wxrw--wt 2 root root 4096 2009-08-27 07:58 wicd
    I'm pretty bad at this stuff, but isn't this rather 1361 than 1363, or am I totally wrong? And why not allow theowner to read the file?
    Last edited by OMGitsUGOD (2009-09-17 08:43:32)

  • GDM update: directory permissions differ on /var/log/gdm/

    Hello,
    Running Arch 64Bits kernel 3.9.9-1 with systemd and i got the following warning during a gdm update today:
    (1/6) upgrading libgdm [######################] 100%
    (2/6) upgrading gdm [######################] 100%
    warning: directory permissions differ on /var/log/gdm/
    filesystem: 711 package: 1770
    Why would gdm need some 1770 permissions for log files? Looks pretty suspicious to me, especially the sticky bit thing. What did i miss?
    PS: BTW the update is successful (it's a warning afterall, not an error)
    Thanks
    EDIT:
    Looks like the opposite situation than 3 years ago:
    https://bbs.archlinux.org/viewtopic.php?id=94681
    https://bugs.archlinux.org/task/19294
    EDIT2: here's what i have in /var/log:
    msytux666 var # ls -la
    total 64
    drwxr-xr-x 14 root root 4096 Jul 6 15:34 .
    drwxr-xr-x 20 root root 4096 Jul 16 20:24 ..
    -rwxrwxrwx 1 root root 4192 Jun 19 11:27 .com.zerog.registry.xml
    drwxr-xr-x 7 root root 4096 Jul 7 00:07 abs
    drwxr-xr-x 8 root root 4096 Jun 16 17:28 cache
    drwxr-xr-x 3 root root 4096 Jun 17 19:07 db
    drwxr-xr-x 2 root root 4096 May 31 20:40 empty
    drwxrwxr-x 2 root games 4096 May 31 20:40 games
    drwx--x--x 2 gdm gdm 4096 Jun 15 14:23 gdm
    drwxr-xr-x 26 root root 4096 Jul 16 01:13 lib
    drwxr-xr-x 2 root root 4096 May 31 20:40 local
    lrwxrwxrwx 1 root root 11 May 31 20:40 lock -> ../run/lock
    drwxr-xr-x 6 root root 4096 Jul 18 00:33 log
    lrwxrwxrwx 1 root root 10 May 31 20:40 mail -> spool/mail
    drwxr-xr-x 2 root root 4096 May 31 20:40 opt
    lrwxrwxrwx 1 root root 6 May 31 20:40 run -> ../run
    drwxr-xr-x 6 root root 4096 Jun 16 17:28 spool
    drwxrwxrwt 8 root root 4096 Jul 18 00:33 tmp
    gdm is owned by gdm, so why would it needs 1770 permissions?
    EDIT3:
    After further research i appear the way gdm is installed may matter.
    Well i installed gdm through pacman and always update it with pacman as well. Never manually compiled/make_install'd it nor used abs for it.
    Last edited by BGK (2013-07-19 21:37:13)

    Okay I'm confused ...
    Commit:https://projects.archlinux.org/svntogit … 92c38d536d
    @@ -68,8 +68,7 @@ package_gdm() {
    cd $pkgbase-$pkgver
    make DESTDIR="$pkgdir" install
    - chmod 1770 "$pkgdir/var/log/gdm"
    - chmod 700 "$pkgdir/var/lib/gdm/.config/dconf"
    + chmod 711 "$pkgdir/var/log/gdm"
    rm -r "$pkgdir/var/run" "$pkgdir/var/gdm"
    ### Split libgdm
    so that takes away the 1770 permissions, and replaces them with 711. 
    @@ -5,6 +5,7 @@ post_install() {
    getent passwd gdm > /dev/null 2>&1 || usr/sbin/useradd -c 'Gnome Display Manager' -u 120 -g gdm -d /var/lib/gdm -s /sbin/nologin gdm
    passwd -l gdm > /dev/null
    chown -R gdm:gdm /var/lib/gdm > /dev/null
    + chown root:gdm /var/log/gdm > /dev/null
    glib-compile-schemas /usr/share/glib-2.0/schemas
    gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
    however:
    chown root:gdm /var/log/gdm > /dev/null
    .. is where I get confused.  This command makes root and the group gdm the new owners of /var/log/gdm, or did I go wrong somewhere?

  • Newly Created Sub-Directories Don't Have Parent Directory Permissions

    Hoping someone may be able to shed some light on this.
    Background:
    Running 10.4.11 as a file server on a PPC G5 in a small creative office. We have a handful of users accessing via AFP. No other services are running.
    I'm using Workgroup Manager as admin tool.
    Top level directory has permissions set to Read & Write for Owner, Group & Everyone.
    Issue:
    When an authenticated user creates a new directory on the server, the new directory does not honor the parent directory permissions for all three user tiers.
    Rather, in getting info, the owner is momentarily set to the user who created the directory with read & write, then switches to (unknown) with r&w. The group is momentarily correct and then switches to (unknown) despite the creating user being part of a specific group, and has Read only permissions.
    Everyone has Read only permissions.
    If a user attempts to fix permissions on a directory they just created, they are unable to do so.
    So, throughout the course of the day, I am bombarded with "I don't have permissions...", wherein, i use remote access to hit Workgroup Manager and do a global propagation down of the parent directories permissions to allow access. Until someone else makes a directory
    This can't possibly be right. Newly created directories should be set to the parent directory permissions, if i'm not mistaken.
    Anyone? Any insight?
    Michael B.

    oh yes.. you are right... its accessible in
    http:://rishtey.local/default_1.html
    successfully... thanks for that... first of all
    now issue is: when i access http://rishtey.local/test.php which contains just a tag to display php info only...
    instead of rendering this php file, it just save the file in the download folder.
    what could be the issue with it?

  • How do I get directory permissions to replicate downward?

    I am trying to modify some directory permissions, but have noticed that the parent directories permissions do not by default replicate downward.  How can I change this so that once the parent folder has been modified, it is reflected into the children directories

    Do a Get Info (command - I) on the parent, unlock if required. set the permissions you want, then go to the gear and select to Apply to Enclosed items.
    I type too slow.

  • How can i change the directory permissions?

    my xampp htdocs directory does not include me as a user but has Nobody? how can i change the directory permissions because i cannot edit a file?
    Thank you

    Select the directory, CMD+I, go to the bottom, unlock the lock, and add yourself to the list with R&W permissions.

  • Repair Home Directory Permissions in Lion

    I currently have my home directory on it's own physical disk (not in the default location on my OS drive).
    When I try to "reset home directory permissions" against my user account in OS X Lion, nothing happens. When I do it for a user who has his home directory on the OS drive, everything works like a champ. The same thing happens under Snow Leopard as well, and I've been trying to track down a solution to this for a long time.
    Does anyone know how to fix this? I tried setting the permissions, ACL's, extended atttributes, etc to the best of my ability using Unix commands, and I'm not really having any issues at the moment, but I'd like to be able to set everything back to the way it should be in my home directory.
    Also, I don't have enough space on my OS drive to move my home directory back to the default location in order to do the reset.
    Any help would be appreciated.
    Bobby

    If you go into System Preferences / Users, you can right click on your User account and choose advanced options. In there, you are able to point your users directory to any disk (or folder) on your machine. I chose to move my home directory to a separate drive in my Mac Pro to make rebuilds easier. Now if I want to reinstall my OS, I simply blow the existing OS away, format the OS disk, and once a fresh OS is installed, I just re-point my account to the existing drive where my home directory is, and all is cool. It's definitely a supported configuration by Apple, and many people do it. It's just aggravating that their "reset home directory permissions" routine doesn't like it.
    My OS drive is a 128gb SSD, and my home directory sits on a 3tb HDD. From a performance and separation perspective it's perfect.
    Bobby

  • Directory permissions differ on var/

    When upgrading packages with pacman, I've been getting a warning that "directory permissions differ on var/  filesystem 775 package 755
    This most recently was during my upgrade of xorg-server
    I'm not sure what causes this warning, or whether some action needs to be taken, and if so, which way to change things.....:(

    http://bbs.archlinux.org/viewtopic.php?id=42314

  • Warning: directory permissions differ

    I am getting an error when downloading and installing packages with pacman.
    This is what I get:
    $ sudo pacman -S nitrogen
    warning: nitrogen-1.2-1 is up to date -- reinstalling
    resolving dependencies...
    looking for inter-conflicts...
    Targets: nitrogen-1.2-1
    Total Download Size: 0.00 MB
    Total Installed Size: 0.13 MB
    Proceed with installation? [Y/n]
    checking package integrity...
    (1/1) checking for file conflicts [#####################] 100%
    (1/1) upgrading nitrogen [#####################] 100%
    warning: directory permissions differ on usr/man/man1/
    filesystem: 755 package: 700
    I don't know if that has a serious impact, but I am sure it shouldn't be like that...

    Snowman wrote:Submit a bug report.
    This is one way and i hope it helps you and the other devs. But what do you think about that the systems can repair this by itselfs? On my opensuse server i have a tool named chkstat which runs as a cronjob and set the file permissions as loaded from a file.
    Source: http://ftp.gwdg.de/pub/opensuse/distrib … 11.src.rpm
    manpage: http://www.trinler.de/de/linux/man.html?command=chkstat
    The advantage from my side is that one or a group of devs define the file permissions standard for arch linux and everyone can choose to use it or to append own more or less secure/paranoid settings. Another sideeffect is that every dev can take a look inside this config file to see what permission the own PKGBUILD need so that in the best case we will not see such messages in the future. The source includes config files so there is no need to restyle this all from zero.

  • Wrong home directory permissions for new users

    Hi everyone.
    I reinstalled my laptop the other day and ran into a rather strange problem: after a system update new users had their permissions totally screwed. It took me 3-4 reinstalls to notice, as i was also playing with lvm2 &co. Anyway, on fresh installations from either 2008.06 or 2009.02, everything works fine. As soon as i update to the latest package versions (including 2.6.29 kernel) and create a new user, permissions on the new home directory are screwed up to the point where the user can't access it.
    Old directory permissions:
    drwx------ 33 jasn users 4,0K 17. Apr 13:21 jasn
    drwx------ 2 root root 16K 17. Apr 12:15 lost+found
    New directory permissions:
    drw-rw--w- 2 jasm users 4,0K 17. Apr 13:43 jasm
    drwx------ 33 jasn users 4,0K 17. Apr 13:21 jasn
    drwx------ 2 root root 16K 17. Apr 12:15 lost+found
    Logging in to "jasm" results in
    No directory, logging in with HOME=/
    [jasm@host /]$
    The whole mess can be fixed by changing the permissions on the home directory, but all that can't be on purpose, can it? I also don't know which package update (if it even was caused by one) causes this behaviour and if this only happens to me, so i didn't file a bug report.
    Has anyone already seen this? I solved it after 1.5 days of puzzled (and strangely unsuccessful) googling and reinstalling, so perhaps someone who runs into the same problem can use this to fix it.
    Last edited by JASN (2009-04-17 17:09:34)

    umask is not really the correct thing to do in this case, as this resets the permissions for every file the user creates. Afaik, the umask setting has to be installed on every machine via the launchd-user.conf file (to contain simply: umask 002) (or whatever is appropriate for your facility), as umask is a property of the process, not the connection.
    What might work better for your problem is make the homedirs world and group non-readable. That way the user creates files within their homedirs and anywhere below, but everyone else can't read them regardless of the files' permissions because the directory itself is unreadable.

  • [SOLVED] Need Help Understanding Warning on Directory Permissions

    Hi guys-
    In my last update I got these warnings:
    warning: directory permissions differ on /usr/share/polkit-1/rules.d/
    filesystem: 700 package: 755
    warning: directory permissions differ on /var/lib/libvirt/qemu/
    filesystem: 755 package: 770
    I've seen quite a few threads floating around like these, but they just add to my confusion. I have not changed persmissions to these files. From what I've gathered so far from a few threads is that the package handler may have changed persmissions resulting in the warning messages. This is where my confusion sets in, and I don't know if it's from staring at the screen for too long, but if I cd into those directories and ls -l, there's the rules.d directory with 700:
    /usr/share/polkit-1/:
    total 8
    drwxr-xr-x 2 root root 4096 Jun 14 10:39 actions
    drwx------ 2 polkitd root 4096 Jun 16 18:31 rules.d
    However, if I cd into rules.d, there's two files in there, both with 644 permissions:
    total 8
    -rw-r--r-- 1 root root 281 Jun 1 02:17 50-libvirt.rules
    -rw-r--r-- 1 root root 488 May 12 17:11 gnome-control-center.rules
    Where's the file with 755?
    Same thing with the other wanring. There's qemu with 755. Libvirt is 755. The directory inside qemu is empty. Where's 770?
    total 36
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 boot
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 dnsmasq
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 filesystems
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 images
    drwxr-xr-x 3 root root 4096 Mar 2 05:39 lockd
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 lxc
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 network
    drwxr-xr-x 2 root root 4096 May 10 19:05 qemu
    drwxr-xr-x 2 root root 4096 Mar 2 05:39 uml
    Can someone help me understand this please?
    Last edited by w201 (2015-06-17 03:23:03)

    The message does indeed mean that the package maintainer has changed the permissions on those directories. You can change your directories to match or leave them as-is. I always change mine when I get messages like this. To do that in this case, you'd run:
    chmod 755 /usr/share/polkit-1/rules.d
    chmod 770 /var/lib/libvirt/qemu
    That will make your directories consistent with the new versions of the packages.

  • Reset Pasword - do I need to reset Directory Permissions and ACLs?

    I reset the password as described below on my mom's computer, as she forgot it.
    http://support.apple.com/kb/HT1274
    I did not reset Directory Permissions and ACLs.
    Do i need to do this?
    Thanks!

    JulieK23 wrote:
    I reset the password as described below on my mom's computer, as she forgot it.
    http://support.apple.com/kb/HT1274
    I did not reset Directory Permissions and ACLs.
    Do i need to do this?
    only if there was something wrong with them. otherwise this is quite independent of resetting the password and is not necessary if all you need is to reset the password.
    Thanks!

  • Mercury Install, directory permissions

    [s3kt0r@localhost ~]$ sudo pacman -S mercury
    resolving dependencies...
    looking for inter-conflicts...
    Targets (1): mercury-1.9.5-1
    Total Download Size: 7.99 MB
    Total Installed Size: 10.97 MB
    Proceed with installation? [Y/n] y
    :: Retrieving packages from community...
    mercury-1.9.5-1-i686 8.0M 311.8K/s 00:00:26 [################################################################################################################################] 100%
    checking package integrity...
    (1/1) checking for file conflicts [################################################################################################################################] 100%
    (1/1) installing mercury [################################################################################################################################] 100%
    warning: directory permissions differ on usr/bin/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/gnome/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/icons/
    filesystem: 755 package: 700
    warning: directory permissions differ on usr/share/pixmaps/
    filesystem: 755 package: 700
    Anyway to fix this?  Thanks

    well 700 on /usr/bin looks like a very bad idea and could indeed partially wreck the system if these permissions were used. (but well, this should all be easily fixable as root).
    But permissions of existing directories are not changed.
    They would only be used if mercury was the very first package installed on a completely empty system. And this would probably never happen in real-world usage.
    So basically, when you have this warning, you do the following :
    1) if filesystem permissions are the correct ones, you are fine. just report a bug for the offending package
    2) if filesystem permissions are the wrong ones, you might want to fix it manually
    3) if you don't know, you can either just ignore the issue, or look for information, or ask around

  • What to do about warning "directory permissions differ on..." ?

    Hello!
    I have gotten this warning when upgrading today:
    warning: directory permissions differ on var/run/gdm/
    filesystem: 1775  package: 711
    warning: directory permissions differ on var/log/gdm/
    filesystem: 1770  package: 755
    This means that the permissions on my computer didn't match with the ones from the package being upgraded/installed, right?
    Which permissions should I leave for that folder (var/log/gdm/) and why? And why is the warning on there twice with different values? i'm confused
    Last edited by trusktr (2010-04-06 18:07:37)

    trusktr wrote:
    Hello!
    I have gotten this warning when upgrading today:
    warning: directory permissions differ on var/run/gdm/
    filesystem: 1775  package: 711
    warning: directory permissions differ on var/log/gdm/
    filesystem: 1770  package: 755
    This means that the permissions on my computer didn't match with the ones from the package being upgraded/installed, right?
    Which permissions should I leave for that folder (var/log/gdm/) and why? And why is the warning on there twice with different values? i'm confused
    If you or another package had good reason to change it, leave it at its current value. If not, change it to the package value listed above (and see if anything breaks).
    You're seeing different permissions for two different folders: read the warnings more closely.

Maybe you are looking for