I have been struggling for the last days with this issue and so far I am not able to find any solution. The issue in a few words is (error message):

H00035: access to index.php denied because search permissions are missing on a component of the path

Where this app is running?

  • the host is Windows 10
  • this is a VM running inside VirtualBox and managed by Vagrant
  • CentOS Linux release 7.5.1804 (Core)
  • Apache/2.4.33 (IUS)
  • PHP 7.2.6 (no that it matters but just in case)
  • SELinux: Enforcing

What I have tried so far:

  • Ran the following commands in the box: It worked? NO (found here)

    find /var/www -type d -exec chmod 755 {} \;
    find /var/www -type f -exec chmod 664 {} \;
    
  • Ran the following commands in the box: It worked? NO (found here)

    chcon -R -t httpd_sys_content_t /var/www
    

Tried everything in here, It worked? NO.

What I did tried and works? Disable SELinux!!! So for sure it's a SELinux miss configuration.

Permissions at /var/www looks like follow:

# namei -mo /var/www/api/public/index.php
f: /var/www/api/public/index.php
 dr-xr-xr-x root    root    /
 drwxr-xr-x root    root    var
 drwxrwxr-x vagrant vagrant www
 drwxrwxr-x vagrant vagrant api
 drwxrwxr-x vagrant vagrant public
 -rwxrwxr-- vagrant vagrant index.php

What else I can try here to fix the issue? I know the easy path would be "disable SELinux" but I do not want to do it it would be better to learn how to do things right :)

This box was built using Puphpet and I can share it. Let me know if you need it for testing purposes.

UPDATE #1:

@hbruijn's answer gave me the idea to change the owner from vagrant to Apache www-data and the H00035 is gone, however I got a new one.

// Before
synced_folder:
    folder1:
        owner: vagrant
        group: vagrant
        source: ../../www/html
        target: /var/www
        sync_type: default

// After
synced_folder:
    folder1:
        owner: www-data
        group: www-data
        source: ../../www/html
        target: /var/www
        sync_type: default

The error as it is right now:

(13)Permission denied: [client 192.168.50.1:2048] AH00529: /var/www/api/public/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/www/api/public/' is executable

This is the output from @hbruijn's answer:

# ls -lZ /var/www/
drwxrwxr-x. www-data www-data system_u:object_r:vmblock_t:s0   api/
-rwxrwxr--. www-data www-data system_u:object_r:vmblock_t:s0   index.html*

I have ran the same command again: find /var/www -type f -exec chmod 664 {} \; but it did not change anything at all which mean permissions remains the same as before.

Any ideas?

migrated from serverfault.com Jun 14 at 13:19

This question came from our site for system and network administrators.

The problem is probably rooted in the fact that you expose part of the host file system as /var/www data in your VirtualBox VM.

Obviously Windows does not have the required file attributes to provide SELinux contexts.

So your VM uses a default security context instead.

The default security context for an "unknown" file system is not a context that aligns well with running a web server.
Check with ls -lZ /var/www/. Your webserver needs something like

drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 /var/www/html 

and currently you're probably getting something different like:

drwxrwxrwx. vagrant vagrant system_u:object_r:vmblock_t:s0 /var/www/api

You can try to manually force the correct SELinux context as a mount option:

mount -o remount,context="system_u:object_r:httpd_sys_content_t:s0" /var/www

and if that works as intended (check with ls -Z) you can probably add that to the mount options is /etc/fstab or your vagrant file

  • The command is failing # mount -o remount,context="system_u:object_r:httpd_sys_content_t:s0" /var/www unknown mount option relatime not sure in how to fix it – ReynierPM Jun 14 at 14:24
  • Also could you take a look to my update in the OP? – ReynierPM Jun 14 at 14:51

restorecon -vRF /var/www will restore the default security context for all files below /var/www. If you haven't changed selinux policies, that should fix it. As a note, if you moved the files elsewhere, you could change those contexts by doing:

semanage fcontext -a -e /var/www /somewhere/www
restorecon -vRF /somewhere/www

In your case, it shouldn't benecessary because /var/www already has defined default labels (eg contexts), but a different directory would not, so you have to change them and then apply them. You can get a idea of pathname to context mappings with grep www /etc/selinux/targeted/contexts/files/file_contexts,

Also, chmod only affects discretionary controls (file permissions), not the mandatory controls (policies) of selinux. Both need to be right for it to work, but if you disabled selinux and it worked, you shouldn't need to do it again.

In addition, /var/log/messages should log all selinux errors and tell you the object that's blocking access. If you do a temporary 'setenforce 0' that will change selinux to permissive mode so that all actions will work but you'll still get the log errors which you can fix them all before turning it back on. If that fails, look at installing the packages setroubleshoot and setroubleshoot-server which will give you even more info.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.