crowdsecurity/crowdsec · error
while removing file: %w
Error message
while removing file: %w
What it means
PurgeCommand.Run deletes the item's downloaded file with os.Remove and wraps any failure other than not-exist. It means the OS refused to unlink the downloaded hub item's file at State.DownloadPath — not that the item was missing (that case is swallowed and treated as already purged).
Source
Thrown at pkg/hubops/purge.go:64
if !i.State.IsDownloaded() {
return false, nil
}
return true, nil
}
func (c *PurgeCommand) Run(_ context.Context, _ *ActionPlan) error {
i := c.Item
fmt.Fprintln(os.Stdout, "purging " + colorizeItemName(i.FQName()))
if err := os.Remove(i.State.DownloadPath); err != nil {
if os.IsNotExist(err) {
i.State.DownloadPath = ""
return nil
}
return fmt.Errorf("while removing file: %w", err)
}
i.State.DownloadPath = ""
i.State.Tainted = false
i.State.UpToDate = false
return nil
}
func (*PurgeCommand) OperationType() string {
return "purge (delete source)"
}
func (c *PurgeCommand) ItemType() string {
return c.Item.Type
}
func (c *PurgeCommand) Detail() string {View on GitHub (pinned to 909b515798)
Solutions
- Re-run the command with sufficient privileges (sudo/admin) so the download path can be unlinked
- Check permissions on the file and its parent directory (ls -l) and correct ownership
- Stop any running crowdsec process holding the file open, then purge again
- Verify the filesystem is writable and not mounted read-only
Example fix
// before cscli hub purge crowdsecurity/http-broken-links // after sudo cscli hub purge crowdsecurity/http-broken-links
Defensive patterns
Strategy: try-catch
Validate before calling
if info, err := os.Stat(item.State.DownloadPath); err == nil {
if info.IsDir() || !canWrite(filepath.Dir(item.State.DownloadPath)) {
// elevate privileges or fix permissions before purging
}
} Try / catch
err := purgeCmd.Run(ctx, plan)
var pe *fs.PathError
if errors.As(err, &pe) && errors.Is(pe.Err, fs.ErrPermission) {
// retry with elevated privileges or fix ownership
} Prevention
- Run hub management commands with the same user that owns the hub directory
- Avoid running some cscli commands as root and others as a normal user (mixed ownership)
- On Windows, close processes holding hub files open before purging
When it happens
Trigger: PurgeCommand.Run on an item with a non-empty DownloadPath where os.Remove fails with something other than os.IsNotExist: e.g. EACCES on the file or parent directory, EBUSY/EPERM on platforms locking open files, or read-only filesystem.
Common situations: Running cscli as non-root while the hub files are root-owned; file still held open by a running crowdsec process on Windows; the data/ config directory is mounted read-only; permissions changed by a previous run as root.
Related errors
- while checking acquisition_path: %w
- while creating directories for %s: %w
- while dumping console config to %s: %w
- while opening %s: %w
- while creating %s: %w
AI-assisted analysis of crowdsecurity/crowdsec@909b515798 (2026-09-06).
Data as JSON: /api/errors/fab84da81fdb6dd7.
Report an issue: GitHub.