Rename and delete are allowed on a volume at VOLUME_ROOT, while create is refused

[MattDHill]

POST /api/files/folder refuses to create anything directly under VOLUME_ROOT:

Cannot create folders in the root path. Please select a specific volume or folder first.

Rename and delete have no matching guard, so an admin can rename or recursively delete an entire volume through the API. The UI doesn't offer either on a volume (no context menu in the Volumes view or the sidebar), so this is only reachable through a direct API call. The asymmetry looks unintentional.

Reproduced on nxzai/explorer:v3.1.0, signed in as an admin, with one volume /mnt/Files:

Request	Body	Result
POST /api/files/folder	{"path":"","name":"Music"}	400, refused
POST /api/files/rename	{"path":"","name":"Files","newName":"Renamed"}	200, /mnt/Files renamed to /mnt/Renamed
DELETE /api/files	{"items":[{"path":"","name":"Files"}]}	200, /mnt/Files removed recursively; GET /api/volumes returns []

Where it happens: routes/files/folder.js checks for an empty parent path, but routes/files/rename.js and resolveDeleteTargets in services/fileTransferService.js don't. Admins get canWrite/canDelete unconditionally in getVolumeAccess, so nothing else stops the request.

Why it matters: a volume is usually a bind mount of real host data, often shared with other applications (media servers, sync tools). One mistaken or scripted request deletes all of it. Renaming it silently breaks every path the other applications and the user-volume assignments hold.

Suggested fix: apply the same empty-parent check to rename and delete. Moves out of the root (transfer.js) probably want it too; I didn't test those.

[cerede2000]

Thank you for the report — precise, and your reading of the code is right: the asymmetry was unintentional.

It is fixed on my fork's integration branch, and it will reach this repository in one of the batches I am sending upstream.

What is refused now, for a volume, the personal folder and an assigned volume alike: rename, delete, move and copy. Creating one was already refused, and the destination of a transfer too.

Two more ways in, which are not in your report: the same delete through the streaming route and through the impact call the confirmation makes first, and an upload started from the list of volumes — its own relative path created a folder there, which is a volume, while POST /api/files/folder refuses exactly that. Both uploads carry the guard, the direct one and the chunked one.

One nuance: it applies to folders at that level, not to a file sitting there. Such a file is not a mount and is not even listed, so refusing to touch it would protect nothing. The kind is read from the disk rather than from the request, since the impact call takes the caller's word for what an item is.

If you want to try it before it lands here, it is in ghcr.io/cerede2000/explorer:test.