chenhg5/cc-connect · error
chmod task script: %w
Error message
chmod task script: %w
What it means
Immediately after writing the task script, schtasksManager.Install calls os.Chmod(scriptPath, 0600) to harden reinstalls (WriteFile only applies perm on create, so pre-existing wider-permission files must be tightened); failure is wrapped as "chmod task script: %w". The script exists and was written, but its permissions could not be narrowed to owner-only.
Source
Thrown at daemon/windows.go:61
if err := os.MkdirAll(DefaultDataDir(), 0755); err != nil {
return fmt.Errorf("create data dir: %w", err)
}
if err := os.MkdirAll(filepath.Dir(cfg.LogFile), 0755); err != nil {
return fmt.Errorf("create log dir: %w", err)
}
scriptPath := windowsTaskScriptPath()
// 0644 has weak semantics on Windows; the file ACL is what matters.
// We still write 0600 so the file's POSIX bits do not advertise read
// access, and rely on the user's own profile ACLs for primary defense
// (the script lives under %USERPROFILE%\.cc-connect by default).
// WriteFile only applies perm on create, so Chmod the existing file
// after writing to harden reinstalls of pre-existing 0644 scripts.
if err := os.WriteFile(scriptPath, []byte(buildWindowsTaskScript(cfg)), 0600); err != nil {
return fmt.Errorf("write task script: %w", err)
}
if err := os.Chmod(scriptPath, 0600); err != nil {
return fmt.Errorf("chmod task script: %w", err)
}
if err := stopWindowsTask(); err != nil {
slog.Warn("schtasks: stop existing task failed", "error", err)
}
if err := deleteWindowsTask(); err != nil {
if windowsTaskMatchesAction(scriptPath) {
if err := m.Start(); err != nil {
return fmt.Errorf("start existing task: %w", err)
}
return nil
}
return err
}
if err := createWindowsTask(scriptPath); err != nil {
return err
}View on GitHub (pinned to 4000b2338a)
Solutions
- Check the wrapped cause; if the file is in use, stop/delete the old scheduled task (`schtasks /end` / `schtasks /delete`) then rerun install
- Fix ACLs on the data directory so the current user has full control (`icacls %USERPROFILE%\.cc-connect /grant "%USERNAME%:(OI)(CI)F"`)
- Remove the stale script (`del <script>`) so it is recreated fresh at 0600 by WriteFile
- If on a filesystem without POSIX permission support, relocate DefaultDataDir to a local NTFS path
Example fix
// before $ cc-connect daemon install // error: chmod task script: chmod ...: Access is denied. // after > schtasks /end /tn "cc-connect" > schtasks /delete /tn "cc-connect" /f > del %USERPROFILE%\.cc-connect\cc-connect-task.ps1 > cc-connect daemon install
Defensive patterns
Strategy: validation
Validate before calling
scriptPath := filepath.Join(os.Getenv("USERPROFILE"), ".cc-connect", "cc-connect-task.ps1")
if info, err := os.Stat(scriptPath); err == nil {
if info.Mode().Perm()&0o077 != 0 {
if err := os.Chmod(scriptPath, 0o600); err != nil {
log.Fatalf("cannot tighten perms on %s (%v); delete the file or stop the running task first", scriptPath, err)
}
}
} Try / catch
if err := daemon.Install(cfg); err != nil && strings.Contains(err.Error(), "chmod task script") {
os.Remove(windowsTaskScriptPath()) // recreate fresh at 0600
return daemon.Install(cfg)
} Prevention
- Delete stale task scripts before reinstalling so WriteFile recreates them at 0600 instead of chmod-ing an old file
- Ensure the current user has full control (icacls) over %USERPROFILE%\.cc-connect so attribute changes succeed
- End/delete the existing scheduled task before upgrade so it does not hold the script open
- Keep the data directory on local NTFS rather than mounts without POSIX permission semantics
When it happens
Trigger: `cc-connect daemon install` when os.Chmod on the freshly written script fails — file locked with a sharing conflict, ACL prevents the owner from changing attributes, or the file sits on a filesystem where POSIX perm bits are not honored and the syscall errors.
Common situations: Reinstalling while the previously registered scheduled task is running and holds the script open; the script inherits deny-ACLs from a hardened folder; unusual volumes (some network mounts, WSL-mounted paths) rejecting chmod semantics.
Understand the failure class
Background: "Permission denied" / "Failed to write" file errors: why a library can't write its files to disk (EACCES, EPERM, ENOSPC) and how to fix them — this error's family across 43 libraries.
Related errors
- create data dir: %w
- write task script: %w
- cannot create config directory: %w
- chmod: %w
- create log dir: %w
AI-assisted analysis of chenhg5/cc-connect@4000b2338a (2026-09-06).
Data as JSON: /api/errors/76c4911a4aad43f1.
Report an issue: GitHub.