sxyazi/yazi · error · io::Error
{e}
Error message
{e} What it means
This error is produced when converting SFTP protocol `Attrs` permissions (`attrs.perm`, a u32 bitmask) into `ChaMode`: the perm field (defaulted to 0 when absent) is truncated to u16 and passed to `ChaMode::try_from`, which rejects values that don't form a valid Unix mode. The failure is mapped to InvalidData, so it indicates malformed or unsupported permission bits returned by the remote server.
Source
Thrown at yazi-vfs/src/engine/sftp/metadata.rs:70
mtime: attrs.mtime.and_then(|t| UNIX_EPOCH.checked_add(Duration::from_secs(t as u64))),
dev: 0,
uid: attrs.uid.unwrap_or(0),
gid: attrs.gid.unwrap_or(0),
nlink: 0,
}))
}
}
// --- ChaMode
pub(super) struct ChaMode(pub(super) yazi_fs::cha::ChaMode);
impl TryFrom<&yazi_sftp::fs::Attrs> for ChaMode {
type Error = io::Error;
fn try_from(attrs: &yazi_sftp::fs::Attrs) -> Result<Self, Self::Error> {
yazi_fs::cha::ChaMode::try_from(attrs.perm.unwrap_or_default() as u16)
.map(Self)
.map_err(|e| io::Error::new(io::ErrorKind::InvalidData, e))
}
}
View on GitHub (pinned to 5f901b886b)
Solutions
- Check what the remote server reports for permissions (log attrs.perm) and confirm server/protocol compatibility
- Update the sftp client/server so modes are reported in standard Unix layout
- Sanitize the perm bits before conversion (mask to 0o7777) at the adapter layer if your server emits extra bits
- Treat it as server data corruption: re-list the directory or reconnect and retry
Example fix
// before ChaMode::try_from(attrs.perm.unwrap_or_default() as u16) // after (mask to valid mode bits first) ChaMode::try_from((attrs.perm.unwrap_or_default() & 0o7777_777) as u16)
Defensive patterns
Strategy: try-catch
Validate before calling
// Server-provided; can't pre-validate the caller's input, but you can sanity-check after stat
let perm = attrs.perm.unwrap_or_default();
if perm & !0o7777_7777 != 0 { // unexpected high bits
log::warn!("server returned non-standard perm bits: {perm:#o}");
} Type guard
fn is_representable_mode(perm: u32) -> bool {
u16::try_from(perm & 0xffff).is_ok() && yazi_fs::cha::ChaMode::try_from((perm & 0xffff) as u16).is_ok()
} Try / catch
match Cha::try_from((name, &attrs)) {
Ok(cha) => cha,
Err(e) if e.kind() == io::ErrorKind::InvalidData => {
// permission bits unusable — fall back to a default Cha
Cha::fallback(name)
}
Err(e) => return Err(e),
} Prevention
- Verify server compatibility: some SFTP servers (Windows, NAS firmware) report non-Unix perm fields
- Mask perm to valid mode bits at the adapter layer before ChaMode conversion
- Update the SFTP client/server when protocol quirks are the cause
- On repeated failures, reconnect and re-stat to rule out corrupted listings
When it happens
Trigger: A remote SFTP server returns an `Attrs` whose perm field doesn't fit a valid Unix file-mode layout (extra/high bits beyond the u16 mode space), or omits perm so the defaulted 0/u16 conversion is rejected by ChaMode's validation.
Common situations: Non-Unix or quirky SFTP servers (Windows OpenSSH, some NAS/firmware servers) reporting permission fields differently, protocol-version mismatches producing unexpected flag combos, or servers returning perm=0 for entries without permission support.
Related errors
AI-assisted analysis of sxyazi/yazi@5f901b886b (2026-09-02).
Data as JSON: /api/errors/cf2a5ebb16034084.
Report an issue: GitHub.