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 '15 at 14:29
  • 1
    run chmod -R u+rwX,go+rX,go-w theme-dir/* – Dusan Bajic Sep 29 '15 at 14:36
  • @dusan.bajic That worked, thanks. Still no idea why it happened in the first place though. – Sal Sep 29 '15 at 14:41
  • 5
    @alexus no corruption, just perms – chicks Sep 29 '15 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 '15 at 19:09

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 '15 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. – Kevin Cathcart Oct 2 '15 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 '15 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. – Bryan 'BJ' Hoffpauir Jr. Oct 1 '15 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.