fatedier/frp · error
failed to sync temp file: %w
Error message
failed to sync temp file: %w
What it means
f.Sync() (fsync) on the temp file failed after a successful write. The library fsyncs deliberately so the store never loses acknowledged writes on crash; a sync error usually indicates a filesystem-level problem, not bad input.
Source
Thrown at pkg/config/source/store.go:164
}
tmpPath := s.config.Path + ".tmp"
f, err := os.OpenFile(tmpPath, os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0o600)
if err != nil {
return fmt.Errorf("failed to create temp file: %w", err)
}
if _, err := f.Write(data); err != nil {
f.Close()
os.Remove(tmpPath)
return fmt.Errorf("failed to write temp file: %w", err)
}
if err := f.Sync(); err != nil {
f.Close()
os.Remove(tmpPath)
return fmt.Errorf("failed to sync temp file: %w", err)
}
if err := f.Close(); err != nil {
os.Remove(tmpPath)
return fmt.Errorf("failed to close temp file: %w", err)
}
if err := os.Rename(tmpPath, s.config.Path); err != nil {
os.Remove(tmpPath)
return fmt.Errorf("failed to rename temp file: %w", err)
}
return nil
}
func (s *StoreSource) persistOrRollbackUnlocked(rollback func()) error {
if err := s.saveToFileUnlocked(); err != nil {
rollback()View on GitHub (pinned to 6c8a8d0a97)
Solutions
- Check kernel logs: dmesg | grep -i 'fsync\|I/O error'
- Move the store to a healthy local filesystem (ext4/xfs) if it currently sits on network/FUSE storage
- Run storage diagnostics (smartctl -a) and replace failing hardware
- After fixing storage, retry the operation — rollback kept in-memory state consistent with the file
Example fix
# before: store on FUSE mount that fails fsync Path: /mnt/nas/frpc/store.json # after: local writable path Path: /var/lib/frpc/store.json
Defensive patterns
Strategy: retry
Try / catch
err := store.UpdateProxy(cfg)
if err != nil && errors.Is(err, syscall.EIO) {
// transient fs error: surface it; retry only after confirming storage health
// state was rolled back, so a plain retry of UpdateProxy is safe
} Prevention
- Keep the store file on a healthy local filesystem (ext4/xfs), not FUSE or flaky network mounts
- Watch dmesg/SMART for I/O errors on hosts running the store
- Because rollback keeps memory and file consistent, a retry after remediation is always safe
When it happens
Trigger: EIO from a failing disk or degraded RAID; fsync on a filesystem/mount that does not support it correctly (some FUSE/network mounts, certain container overlays); vm writeback errors surfaced at fsync time.
Common situations: FUSE/NFS-backed store paths in containers; dying SD-card/eMMC deployments (edge gateways); kernel writeback errors after storage disconnect.
Related errors
- failed to close temp file: %w
- failed to write temp file: %w
- failed to load existing data: %w
- failed to create directory: %w
- failed to create temp file: %w
AI-assisted analysis of fatedier/frp@6c8a8d0a97 (2026-08-15).
Data as JSON: /api/errors/75305d155e331a99.
Report an issue: GitHub.