fix: guard volume file browser against non-mountable driver types

[GiulioSavini]

What

Volumes created with type=none (or other custom local driver options like o=bind,device=...) cannot be mounted inside a helper container — Docker fails with failed to mount local volume: no such device.

Before this fix, the error bubbled up as a confusing daemon-level message. Now the volume options are checked upfront and a clear, user-friendly error is returned instead of trying to spin up a temp container that was never going to work.

Changes

• Added isBrowsableVolumeInternal helper in volume_service.go that inspects the volume's driver options before mounting
• Applied the guard to all three browsing entry points: ListDirectory, GetFileContent, DownloadFile

Testing

Create a volume with the advanced driver options type=none, o=bind, device=/some/path. Navigate to the Browser tab — you'll now get a clear error instead of a daemon stacktrace.

Fixes #2359

Disclaimer Greptiles Reviews use AI, make sure to check over its work.

To better help train Greptile on our codebase, if the comment is useful and valid Like the comment, if its not helpful or invalid Dislike

To have Greptile Re-Review the changes, mention greptileai.

Greptile Summary

This PR adds a isBrowsableVolumeInternal guard that inspects a volume's driver options before spinning up a helper container, returning a user-friendly error for type=none volumes that would otherwise produce a confusing daemon-level "no such device" failure. The guard is correctly wired into all three browsing entry points (ListDirectory, GetFileContent, DownloadFile) and follows the repo's naming and error-wrapping conventions.

Confidence Score: 5/5

Safe to merge — the fix is targeted, correct for the reported bug, and all remaining feedback is P2.

No P0 or P1 findings. The nil-map access on vol.Options is safe in Go. Error wrapping follows idiomatic patterns. The only suggestion is broadening the guard condition to cover additional bind-variant configurations, which is a non-blocking improvement.

No files require special attention.

Prompt To Fix All With AI

This is a comment left during a code review.
Path: backend/internal/services/volume_service.go
Line: 267-276

Comment:
**Guard only checks `type=none`**

The current check catches the primary failure mode (`type=none`), but other local-driver configurations can also fail to mount in a helper container — for example, a volume created with just `o=bind,device=/path` and no explicit `type` key, or `type=tmpfs` (which mounts successfully but always appears empty). Adding a check for `device` or `o=bind` would harden the guard against related edge cases.

```suggestion
func (s *VolumeService) isBrowsableVolumeInternal(ctx context.Context, volumeName string) error {
	vol, err := s.GetVolumeByName(ctx, volumeName)
	if err != nil {
		return fmt.Errorf("failed to inspect volume: %w", err)
	}
	if vol.Options["type"] == "none" || strings.Contains(vol.Options["o"], "bind") {
		return fmt.Errorf("volume %q uses a custom mount type (%q) and cannot be browsed", volumeName, vol.Options["type"])
	}
	return nil
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: guard volume browser against non-mo..." | Re-trigger Greptile}

Greptile also left 1 inline comment on this PR.

[kmendell]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.