fscrypt_prepare_setattr(9)

💅 fscrypt_prepare_setattr(9) 💅

okay bestie, this page is from the Kernel API Manual, and it’s lowkey essential for anyone touching a possibly-encrypted inode. let’s get into it 🦋

---

🎀 NAME 🎀

fscrypt_prepare_setattr — prepare to change a possibly-encrypted inode’s attributes ✨

✨ SYNOPSIS ✨

int fscrypt_prepare_setattr (struct dentry *dentry , struct iattr *attr
);

🫶 ARGUMENTS 🫶

• dentry — the dentry through which the inode is being changed. that’s the doorway, bestie 🚪✨
• attr — the attributes to change. slay, let’s edit some metadata 💅

🔥 DESCRIPTION 🔥

okay so the whole vibe is: prepare for ->setattr on a possibly-encrypted inode. no cap. On an encrypted file, most attribute changes are allowed even without the encryption key — iconic behavior, honestly. BUT without the encryption key we do have to forbid truncates. periodt.

Why? because the size being truncated to may not be a multiple of the filesystem block size, and in that case we’d have to decrypt the final block, zero the portion past i_size, and re-encrypt it. that’s giving “whole extra chore” 😭

(we could allow truncating to a filesystem block boundary, but it’s simpler to just forbid all truncates --- and we already forbid all other contents modifications without the key.) so yeah, truncates are not invited to the no-key party 💀

⭐ RETURN ⭐

0 on success, -ENOKEY if the key is missing, or another -errno code if a problem occurred while setting up the encryption key. that’s the return vibe check 💖

🌈 SEE ALSO 🌈

• Kernel file ./include/linux/fscrypt.h
• fscrypt_needs_contents_encryption(9)
• fscrypt_is_nokey_name(9)
• fscrypt_has_encryption_key(9)
• fscrypt_prepare_link(9)
• fscrypt_prepare_rename(9)
• fscrypt_prepare_lookup(9)
• fscrypt_prepare_readdir(9)
• fscrypt_encrypt_symlink(9)

---

mwah 💋 — source/version: ./include/linux; date: October 2026. periodt. 🎀