inode_init_owner(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… inode_init_owner β€” like, the kernel API manual edition πŸŽ€

okay so bestie, this is inode_init_owner(9) straight out of the Kernel API Manual, and it's the function that sets up a brand-new inode's uid, gid, and mode the way POSIX says you should. no cap, it's a small function with big main character energy. ✨


πŸ’– SYNOPSIS

void inode_init_owner (struct mnt_idmap *idmap , struct inode *inode ,
const struct inode *dir , umode_t mode );

that's the whole signature, fr fr. four params, one void return, zero drama. 🫢


🌸 ARGUMENTS

  • idmap β€” the idmap of the mount that this inode was created from. yes, that idmap. πŸ‘€
  • inode β€” the new inode, freshly born, needs its identity set. it's giving newborn era. 🍼
  • dir β€” the directory inode. the parent. the one who raised it. 😭
  • mode β€” the mode of the new inode. the vibe check of file permissions, basically. πŸ’…

πŸ¦‹ DESCRIPTION

okay so here's the tea πŸ“: if the inode was created through an idmapped mount, you have to pass the vfsmount's idmap through idmap. like, non-negotiable. then this function will take care of mapping the inode according to idmap before it goes and checks permissions and initializes i_uid and i_gid. nobody skips the mapping step on its watch. πŸ’―

and if you're on non-idmapped mounts? or if permission checking is supposed to happen on the raw inode? then just pass nop_mnt_idmap and keep it moving, bestie. πŸ™ˆ


🧚 SEE ALSO

literally the entire inode cinematic universe, all in ./fs/inode.c under Kernel file β€” go read them all, i'm obsessed:


πŸ’€ reminder that this page lives in ./fs and is dated October 2026 β€” so like, mark your calendar bestie, that's the versioning era we're in. 🌈

and that's the whole page!! mwah πŸ’‹ stay hydrated, pass your idmaps correctly, and remember: nop_mnt_idmap is your bestie when there's no idmapped mount in sight. πŸŽ€βœ¨πŸ’œ

πŸ“¦ where this page comes from