juicedata/juicefs · error
getattr inode %d: %s
Error message
getattr inode %d: %s
What it means
When resolving a directory path (e.g. for session info or subdir display), getDirPath walks parents via doGetAttr; if getattr on an inode fails, this error wraps the status code. It means an inode in the ancestor chain could not be stat'ed — typically a dangling or concurrently-deleted ancestor, or a metadata lookup error.
Source
Thrown at pkg/meta/base.go:2364
}
}
func (m *baseMeta) GetPaths(ctx Context, inode Ino) []string {
if inode == RootInode {
return []string{"/"}
}
if inode == TrashInode {
return []string{"/.trash"}
}
outside := "path not shown because it's outside of the mounted root"
getDirPath := func(ino Ino) (string, error) {
var names []string
var attr Attr
for ino != RootInode && ino != m.root {
if st := m.en.doGetAttr(ctx, ino, &attr); st != 0 {
return "", fmt.Errorf("getattr inode %d: %s", ino, st)
}
if attr.Typ != TypeDirectory {
return "", fmt.Errorf("inode %d is not a directory", ino)
}
var entries []*Entry
if st := m.en.doReaddir(ctx, attr.Parent, 0, &entries, -1); st != 0 {
return "", fmt.Errorf("readdir inode %d: %s", ino, st)
}
var name string
for _, e := range entries {
if e.Inode == ino {
name = string(e.Name)
break
}
}
if attr.Parent == RootInode && ino == TrashInode {
name = TrashName
}View on GitHub (pinned to c9a67b23e8)
Solutions
- Re-mount with a valid existing subdirectory path (--subdir) and avoid deleting mounted ancestors
- Check metadata consistency (juicefs fsck) for dangling inodes/parent links
- Investigate the underlying doGetAttr status from metadata engine logs
Example fix
// before: subdir deleted while mounted juicefs mount redis://meta /jfs --subdir /gone // after: use an existing subdir juicefs mount redis://meta /jfs --subdir /data
Defensive patterns
Strategy: try-catch
Validate before calling
// before mounting with --subdir, verify the path exists: // juicefs info <meta-url> /data
Try / catch
if _, err := buildDirPath(ctx, rootIno); err != nil { if strings.Contains(err.Error(), "getattr inode") { log.Warnf("ancestor missing; remount required: %v", err) } } Prevention
- Never delete directories that are mount roots/subdirs of running clients
- Run `juicefs fsck` after suspected metadata corruption
- Use stable, dedicated paths as subdir mount points
When it happens
Trigger: An ancestor inode of m.root was deleted while building the path; metadata engine lookup failure returning a nonzero status for an internal inode; corrupted parent links.
Common situations: Deleting the mounted subdirectory while a client is running; metadata inconsistencies after failed loads; races during concurrent rm -rf of ancestor directories.
Understand the failure class
Background: "Not found" and "does not exist" errors: why "Task not found", "No such folder", and "Can't find" fire when a lookup comes back empty — this error's family across 14 libraries.
Related errors
- inode %d is not a directory
- readdir inode %d: %s
- lookup inode for %s: %s
- get inode of %s: %s
- Mkdir %s: %s
AI-assisted analysis of juicedata/juicefs@c9a67b23e8 (2026-09-06).
Data as JSON: /api/errors/4cb34b36cadc3de2.
Report an issue: GitHub.