Recursive chmod and Why 755 Across a Source Tree Is Wrong

The problem with chmod -R is that a directory and a regular file want different things from the same nine bits. Directories need execute for traversal. Data files should not have it. One recursive mode cannot satisfy both, so chmod -R 755 leaves every stylesheet and JPEG marked as a program, and chmod -R 644 leaves a tree that nobody can enter, including the person who ran it.

The second of those is the more alarming and the easier to fix, because the failure is immediate and total. The first is worse in practice: it looks like it worked, it shows up as a mode change on every file in version control, and it defeats any tooling or audit that treats an unexpected executable as a signal.

There are two clean patterns. Two find passes, one for directories and one for files, is explicit and reads well in a script. The capital X form does it in one command, because X sets execute only on directories and on files that already had an execute bit somewhere, which preserves genuine scripts while leaving data alone.

Symbolic links are handled sensibly and quietly. chmod cannot change the mode of a symbolic link itself, since the mode is not used, and it does not follow links encountered during a recursive walk. That means a recursive chmod through a tree containing a link to somewhere else will not wander into that other tree, which is the behaviour you want and the opposite of what many people assume.

Before running anything recursive, look at what it will touch. A dry run with find and no -exec prints the list, and the calculator's recursive checkbox shows the exact command it would produce, including the -R flag and the shell quoting for a path with spaces in it. Reading the command before running it is the whole safety procedure.