I was adjusting the permissions when setting up some WordPress themes, and ran chmod 664 -R theme-dir/* It worked fine on the files in the root of the directory, but all the files in subdirectories now read like this when I ls -l:

?---------  ? ? ? ?            ? core_functions.php
?---------  ? ? ? ?            ? css
?---------  ? ? ? ?            ? custom_functions.php
?---------  ? ? ? ?            ? images
?---------  ? ? ? ?            ? import_settings.php
?---------  ? ? ? ?            ? js
?---------  ? ? ? ?            ? options_trim.php
?---------  ? ? ? ?            ? page_templates
?---------  ? ? ? ?            ? post_thumbnails_trim.php
?---------+ ? ? ? ?            ? shortcodes

I can't cd to any of the subdirectories, and I also can't delete them. I've never seen anything like this, anybody ever run into something similar?

  • looks like corrupted file system..
    – alexus
    Sep 29, 2015 at 14:29
  • 1
    run chmod -R u+rwX,go+rX,go-w theme-dir/* Sep 29, 2015 at 14:36
  • @dusan.bajic That worked, thanks. Still no idea why it happened in the first place though.
    – Sal
    Sep 29, 2015 at 14:41
  • 5
    @alexus no corruption, just perms
    – chicks
    Sep 29, 2015 at 15:37
  • I think I saw something like that when I did chown 644 (or whatever) versus chmod, but I really don't feel like testing again on a working system
    – Foon
    Sep 29, 2015 at 19:09

2 Answers 2


Accessing the contents (or more specifically file metadata except for filename) of a directory requires that the directory have the execute bit set.

Your recursive chmod removed that permission, so you lost that access. If you are using the -R option of chmod is better to avoid using the numeric version of the permissions, and instead run (using your desired state as an example) chmod -R ug=rwX,o=rX. The capital X there means set the X bit only on directories or files that have at least one x set. Also you might want to use 644 (u=rwX,go=rX) unless you really need group users to write.

  • 6
    X means set X on directories and files that already have execute permission for some user (which is usually what you want)
    – tomclegg
    Sep 30, 2015 at 5:01
  • 1
    @tomclegg: Right. I updated my answer appropriately. It does seem odd that they never added a true directory specific version, or even better a pre-operation letter (like the u, g, o, or a) that means apply this change only to directories. Oct 2, 2015 at 15:03

From the Wordpress documentation:

If you have shell access to your server, you can change file permissions recursively by using the following commands:

For Directories:

find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;

For Files:

find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;
  • An overkill for this particular problem, but very useful in other cases :)
    – nurchi
    Oct 1, 2015 at 0:58
  • 1
    I've noticed in more security sensitive environments (Magento and Health Care Systems recently) that vendors and open source systems are moving to recommending ONLY using the file method since it gives you kite granular control over the above condition and also allows fine grained control of application of setuid, setgid and also the infamous "sticky bit". It probably is more work to map this out for this use case but the bet answer is always the most secure method that achieves the desired outcome. I believe Security should always be Feature #1 if its possible to afford it. Oct 1, 2015 at 2:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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