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

  1. Check kernel logs: dmesg | grep -i 'fsync\|I/O error'
  2. Move the store to a healthy local filesystem (ext4/xfs) if it currently sits on network/FUSE storage
  3. Run storage diagnostics (smartctl -a) and replace failing hardware
  4. 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

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


AI-assisted analysis of fatedier/frp@6c8a8d0a97 (2026-08-15). Data as JSON: /api/errors/75305d155e331a99. Report an issue: GitHub.