When bulk renaming refuses to work

A batch rename mac finder problem almost always falls into one of three shapes. The Rename item is not in the menu at all. The panel opens, the button is clickable, and afterwards the names are unchanged. Or most files get renamed and a handful stubbornly keep their old names. Those three shapes have completely different causes, and separating them first turns a vague failure into a short checklist. Nothing below requires installing anything.

Matching the symptom to the cause

Before opening any Info window, it is worth deciding which of the three shapes is on screen. Each one points at a different half of the machine.

Symptom	Likely cause	Where to check
No Rename entry in the menu	fewer than two items selected	status bar item count
Panel runs, names unchanged	file is locked	Get Info, Locked checkbox
Panel runs, names unchanged	folder is read only	Get Info on the enclosing folder
Everything fails on one drive	volume mounted read only	Get Info on the drive, Format line
Most files rename, a few do not	cloud placeholders or duplicate names	cloud badges in the file list
Rename is refused instantly	illegal character or name too long	the text being inserted

The rows split cleanly. The first three are about a single file or folder, the fourth is about a whole volume, and the last two are about the names being produced rather than the files receiving them. Deciding which group applies takes a few seconds and removes most of the checklist.

The menu item is missing

The rename panel appears only when more than one item is selected. With a single file selected, Control-clicking offers inline renaming instead, and no panel opens. This catches people constantly, because the two menus look almost identical at a glance.

On your Mac, select the items, then Control-click one of them. In the shortcut menu, choose Rename. Source: support.apple.com

The subtler version of this is a selection that has silently been cleared. Clicking into a Finder window selects nothing. Navigating to another folder and back drops the selection. Switching view modes can drop it too. Turn on the status bar from the View menu, and the item count at the bottom of the window will confirm what is actually selected before anything else gets investigated.

Mixing files and folders in one selection is fine. What is not fine is including a disk, a system-managed folder, or an item macOS protects. In that case the panel still opens, and only the protected entries are refused when the rename runs.

The panel runs but the names come back

When the rename appears to succeed and nothing changes, the first thing to check is the lock. Select a file, press Command+I, and look near the top of the Get Info window for the Locked checkbox. A locked item accepts neither renaming nor deletion.

That checkbox maps to a file flag. Running ls -lO shows uchg on the affected rows, and any attempt to rename such a file from the command line returns Operation not permitted. Clearing it one file at a time is slow, but selecting several files and pressing Command+I opens a single combined Info window whose Locked checkbox applies to all of them at once.

Locks arrive without anyone setting them deliberately. Documents that came in as email attachments, files copied from another Mac, items restored from a backup, and files written by accounting or design applications that lock their own output are the usual sources. A folder where roughly half the files are locked and half are not almost always has a mixed history like that.

Permission belongs to the folder, not the file

If nothing is locked and the rename still does not stick, the next stop is permissions, and this is where the diagnosis usually goes wrong. Renaming does not require write access to the file. It requires write access to the folder the file sits in.

A file whose own permissions read Read & Write cannot be renamed if its enclosing folder is read only. From the command line the result is Permission denied, on a file that ls -l clearly shows as writable. The reason is structural: a name is an entry in the parent directory's listing, so changing it means writing to that listing. Finder does not surface this distinction anywhere, which is why checking the file's own Info window leads to a dead end.

The fix is to select the enclosing folder rather than the file, press Command+I, and expand Sharing & Permissions at the bottom. An account showing Read only there is the answer. On an external drive, the same panel offers Ignore ownership on this volume, which skips permission checks entirely for that disk. Drives inherited from another person's Mac are the common case, and that single checkbox usually resolves them.

The drive is mounted read only

External disks introduce a failure that looks like a permissions problem but is not one. If the volume is NTFS, macOS mounts it read only by default. Files are visible, they copy off perfectly well, and every attempt to rename or save fails.

To confirm, select the drive icon, press Command+I, and read the Format line. Windows NT File System there means read only, and no permission change will alter that. The two options are to copy the files to the Mac, rename them there, and copy them back, or to reformat the drive in a format macOS can write. Reformatting erases the disk, so copying comes first.

The same read only condition shows up on SD cards with the physical write-protect switch engaged, on disk images opened read only, and on Time Machine backup volumes. Time Machine snapshots are deliberately immutable, so files inside a backup cannot be renamed in place at all. Restore them first, then rename the restored copies.

A few files stay behind because they are not really there

The pattern where most files rename and a few do not is nearly always cloud sync. With iCloud Drive storage optimisation active, files that have not been opened recently are evicted from the disk and only a placeholder remains, marked with a cloud icon. Renaming one triggers a download first, and across a large selection that queue can stall or time out.

Fixing it is a matter of order. Control-click the folder, choose Download Now, wait for the cloud badges to disappear, then run the rename. Anyone with Desktop and Documents stored in iCloud Drive should expect this to apply to those two folders specifically.

Third-party sync clients produce a related failure. Renaming a file while it is mid-upload can result in the old name being written back once the sync completes, which looks exactly like the rename silently failing. Waiting for the menu bar icon to stop showing activity avoids it. Shared folders add one more condition: an account invited with view-only access cannot rename anything, and every attempt will be reverted by the server no matter what the local machine does.

Names the file system will not accept

Sometimes the rename is refused because the resulting name is illegal rather than because the file is protected.

You can use numbers and most symbols. You can't include a colon (:) or start the name with a period (.). Some apps may not allow you to use a slash (/) in a filename. Source: support.apple.com

Putting a timestamp such as 10:30 into a name hits this immediately. A period or a hyphen works instead. Length matters too: a single name component is capped at 255 characters, and adding a long prefix with Add Text will push exactly the files that already had long names past that limit while every other file succeeds.

Duplicate names stop the operation as well. A misconfigured Format pattern can resolve several files to the same target name, and Finder refuses the second and subsequent ones rather than overwriting them. That is the safe behaviour, and it is also the reason a rename can report fewer changes than files selected.

Case-only changes have their own trap. The default APFS volume is case insensitive, so Report.pdf and report.pdf cannot coexist in one folder. Lowercasing a whole folder will therefore collide wherever two names differ only in capitalisation.

Places that are protected on purpose

Some items are not meant to be renamed at all, and macOS enforces that.

App folders and any items that came with your system, such as the Library folder. (If you change the name of an item and experience problems, change the name back.) Source: support.apple.com

The standard folders inside a home folder, Documents and Pictures and Downloads among them, belong to the same category. Applications locate them by name, so renaming them breaks saving.

The other confusing case is a bundle: something that looks like one file but is actually a folder. Photo libraries, some application documents, and applications themselves all work this way, and Control-clicking one shows Show Package Contents. Running a batch rename inside a bundle will usually break it, because the application locates its own internal files by name. Renaming photographs in bulk should happen on exported copies, never inside the library.

What Finder does not do at all

If every cause above has been ruled out, the remaining possibility is that the operation is not supported rather than failing. The panel offers three modes: replace a literal string, add a fixed string before or after, or append an index, counter, or date. There are no wildcards and no regular expressions. Reordering the parts of a name, zero-padding an existing number, or applying a rule only to files that match a condition are all outside its scope.

Three routes cover the gap. zmv, which is bundled with zsh and needs no installation. A Shortcuts workflow built around the Rename Finder Items action. Or the same action saved as an Automator Quick Action so it appears in the right-click menu. The terminal is the fastest for a one-off, and the other two are better when the same rename will be repeated weekly.

What to change first

Run the same operation on just two files before investigating anything else. If two files succeed, the cause lives in specific files, meaning locks, cloud placeholders, or illegal resulting names. If two files fail, the cause is the location, meaning folder permissions or a read-only volume. That single test halves the search space.

When the checking itself is the slow part, because a lock check, a permission check, and an ls -lO each happen in a different window, the friction is layout rather than knowledge. A file manager that keeps the listing and a terminal on the same working directory removes those switches, which is the idea behind Atriens, and the comparison page sets it against two-pane and terminal-first tools.