What file permissions does mv need?

What Unix file permissions are required for mv path/to/src/file path/to/dest, assuming that dest/ is an existing directory that is not src/?

Neither I nor ChatGPT nor any of the dozen programmers I asked could give a completely correct answer off the top of their heads.

If you'd like, take a moment to think about it for yourself. Otherwise, scroll down to see the answer.

1. +w on src/ and dest/
2. +x on every directory named in path/to/src/ and path/to/dest/, including the implicit current directory for relative paths
3. If file is a directory on the same filesystem as dest/, +w on file
4. If src/ has the sticky bit set, then you must be either the owner of file or the owner of src/
5. If src/ and dest/ are on different filesystems, then +r on file
6. If src/ and dest/ are on different filesystems and file is a directory, then +r on every regular file and directory in file (and all subdirectories), and +wx on every non-empty directory.

(This was tested on Linux and macOS. Email me if you think I've missed something.)

Commentary:

• Many thought you needed permissions on f itself, but – aside from the edge cases #3 and #5 – you do not, because renaming a file does not require either reading or altering its contents, only the contents of the source and target directories (hence #1).
• Quite a few people had a vague idea that execute permissions had some special meaning for directories, but only a couple specifically knew that they are needed to access paths within that directory, and no one mentioned that you need execute not just on src/ and dest/ but also all the other directories in the path.
• No one remembered #3. Admittedly, it's a bit of an ad hoc requirement that only exists because a directory has a special .. entry that points to its parent, which must be updated if a directory is moved. Interestingly, if src/ and dest/ are the same, +w is required on macOS but not on Linux.
• #4 sounds like arcana, but it applies to at least one very well-known directory: /tmp. The sticky bit is intended for shared directories so that a user cannot interfere with others' files – hence the ownership permissions required.
• Likewise, #5 and #6 apply to /tmp, which is typically mounted as its own filesystem. The rename syscall doesn't work across filesystems, so the mv command emulates it by reading the source file, unlinking it from the source directory, and recreating it in the target directory. Because it has to read the contents of the file, +r permissions are necessary.

What does it mean for me?

• #2 applies to accessing paths generally, so it's good to know besides its implications for mv.
• To prevent others from moving files out of a directory (or renaming them), deny them write permissions.
• You should probably be aware that mv does something completely different when moving between filesystems (another implication is that it is not atomic). You should probably also be aware that /tmp is typically a different filesystem.
• If you are trying to mv something and hitting a permissions error, you may need to work your way through this list.

Further reading

• man 2 rename covers the first three requirements under EACCES in the "Errors" section.
• man 7 path_resolution describes the Linux path resolution process.
• "against /tmp" covers the meaning of the sticky bit.
• Sections 4.5 and 4.15 of Advanced Programming in the Unix Environment cover Unix file permissions and rename, respectively. ∎