Why Can a Mounted Filesystem Create Files but Reject Renames?

A mounted filesystem can allow file creation yet reject renames because rename has separate directory, ownership, boundary, flag, and open-handle requirements.

A successful mount only proves the filesystem is attached, and a successful file write proves the client can create or modify at least one object. Rename is a directory-entry operation that may require permission on both source and destination directories, deletion rights, a same-filesystem path, a valid target name, and no conflicting SMB share mode or protected file flag. Capture the exact error and compare create, rename, move, and delete separately before treating the filesystem as damaged.

Capture the Exact Rename Error Before Changing Permissions

Repeat one rename from the host and from the affected client. Record the source path, destination path, user identity, filesystem, mountpoint, error code, and whether the target name already exists.

The Linux rename system call errors distinguish permission failures, busy mountpoints, cross-device moves, read-only filesystems, nonempty targets, and other conditions that can look identical in a graphical file browser.

If creating a new file succeeds but renaming it fails, preserve that contrast. It narrows the problem to directory-entry replacement, deletion permission, naming rules, locks, or a path boundary rather than ordinary write access.

Check Permissions on Both Parent Directories

Inspect ownership, mode bits, ACLs, and effective identity on the directory containing the old name and the directory that will contain the new name. Rename permission is determined primarily by the directories, not by the file’s write bit.

Red Hat explains that the sticky bit restricts rename and deletion in shared writable directories to the file owner, directory owner, or privileged user even when multiple users can create files there.

Test with the same NAS user that receives the error. Administrator success does not prove the ordinary account has delete or rename rights on both directory entries.

Inspect Immutable, Undeletable, and Append-Only Flags

Check filesystem flags on the file and its parent directories in addition to ordinary permissions and ACLs. Restores, security tools, or retention workflows can preserve flags that are not visible in a basic permission listing.

The FreeBSD security handbook notes that an immutable file flag prevents modification or deletion, while append-only and undeletable flags can also block the directory changes required for rename.

Remove a protective flag only after identifying which policy or application set it. Clearing flags globally can defeat retention, backup, or ransomware-protection controls.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Rule Out a Cross-Filesystem Move Hidden Behind One Folder Tree

Resolve the source and destination directories to device IDs, mountpoints, bind mounts, datasets, and container paths. Two folders under the same share can still belong to different mounted filesystems.

The GNU C Library defines EXDEV as a cross-device rename error. A higher-level move tool may recover by copying and deleting, while an application that expects an atomic rename may simply fail.

If a local move succeeds only by copying the entire file, the operation was not an atomic rename. Correct the application’s temporary and final paths or keep both stages on the same filesystem.

Check Open Handles and SMB Delete Sharing

List open files and SMB sessions for the source and target directories. Close previewers, thumbnail generators, editors, media scanners, antivirus tools, and backup clients one at a time.

Microsoft documents a network-folder case where an open thumbnail-cache handle blocks rename, showing why the ability to read or create other files does not clear a sharing violation on the specific object.

Do not restart the entire NAS before preserving the open-handle evidence. A reboot may release the lock while hiding which client or service recreated it.

Compare SMB Rename Rules With the Client’s Filename

Test a simple lowercase ASCII name in the same directory. Then compare case-only changes, reserved characters, trailing periods or spaces, Unicode normalization, and an existing destination name.

Samba’s macOS interoperability module provides a POSIX rename compatibility option, illustrating that client and server naming semantics can change whether a directory rename is accepted.

If only one filename pattern fails, preserve the original name mapping before normalizing it. Bulk renaming without a rollback list can break media libraries, sync jobs, shortcuts, and backups.

Repair the Proven Layer and Verify Every Operation

Correct only the verified cause: parent-directory permission, sticky-bit ownership, protected flag, same-filesystem path, open handle, or incompatible filename. Repeat the test with the original user and application.

The ZimaSpace article on case-only filename collisions covers the narrower cross-platform case where two names become equivalent at the destination.

The issue is resolved when create, close, rename, move, delete, and recreate all succeed in the intended path after reconnect and reboot. Stop writes if the filesystem becomes read-only or reports corruption or hardware I/O errors.

Frequently Asked Questions

Why can I create a file but not rename it?

Creation needs permission to add a directory entry, while rename can also require removal rights on the old entry, write and execute rights on both parent directories, compatible naming rules, and no protected flags or conflicting handles.

Does an EXDEV rename error mean the filesystem is damaged?

No. It usually means the source and destination are on different filesystems, so the kernel cannot complete one atomic rename. A copy-and-delete move may still work.

Can an open file be renamed?

Many local POSIX filesystems permit it, but SMB clients and applications can open files without delete sharing, which causes the server to reject the rename until the handle closes.