mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-07-26 11:49:16 +00:00
Anso
b9d8e9f490
* feat(stacks): browse and edit mounted volume files in the explorer Reposition the stack file explorer around runtime configuration access: discover a stack's declared mounts and expose each as a safe, stack-scoped file root. The explorer opens on a Volumes group (bind mounts and named Docker volumes) by default, with the stack source directory as a secondary group, on a "Files & Volumes" tab. - Discover roots from the rendered effective compose model; resolve named volumes to their Docker name and browse/edit them through the hardened helper container, with bind mounts handled directly when reachable. - Re-derive the allowed roots server-side on every file operation and match the client root id against them, so a request can never address a path the stack did not declare. Block dangerous host mounts and binds that overlap Sencho's managed directories; reject writes to read-only mounts. - Thread an optional root id through the existing file endpoints and an opaque, parseable optimistic-concurrency token through read, conflict, and write, for both filesystem and helper backends. - Keep compose and env file protection on the stack source root only. * fix(stacks): theme the Files & Volumes root switcher Replace the raw native select in the file-root switcher with the design system Select component. The native control did not honour the dark theme, so the panel rendered white with unreadable text. The themed Select gives a dark popover with grouped Volumes / Stack source labels and disabled items. * fix(stacks): contain the bind-root probe and de-taint the file-op error log Gate the volume-root bind probe's realpath/stat behind a compose-base containment check (mirroring the storage host-path probe) so they never run on an unvalidated host path; a source outside the compose dir is unreachable in the containerized deployment anyway and is reported non-accessible without touching the filesystem. Log the helper-backed file-op failure through a constant format string with sanitized arguments instead of an interpolated template literal. * fix(stacks): inline the bind-probe containment guard at the fs sinks The wrapped containment predicate was not recognized as a path barrier, so the bind probe's realpath/stat still flagged as uncontrolled-data-in-path. Inline the path.resolve + startsWith check directly at each filesystem sink (and re-check the resolved canonical before stat, so a within-base symlink that resolves outside the compose dir is also rejected). * fix(stacks): harden file-root lifecycle, upload race, and helper errors Address review findings on the Files & Volumes feature: - Invalidate the file-root allowlist on stack create/delete/import/from-git (wire StackFileRootsService.invalidateNode into invalidateNodeCaches), so a stack deleted and recreated under the same name cannot serve the old stack's roots from the 15s cache. - Use the atomic exclusive write for a non-overwrite upload so a file created by another writer after the existence check is not silently clobbered. - Let the helper's real cd errno through and map permission failures to 403 consistently across list/stat/read/write/mkdir/delete/pathKind, instead of reporting EACCES as 404/500; pathKind no longer reports a permission-denied parent as absent. - Document the realpath-then-open TOCTOU as a known, pre-existing limitation of every file op (O_NOFOLLOW is not viable because config volumes legitimately contain symlinks); the bind root is contained to the compose dir and the op requires stack:edit. - Docs: drop a missing screenshot reference and correct the protected-file delete behavior (stack-root compose/.env cannot be deleted via the explorer).
262 lines
19 KiB
Plaintext
262 lines
19 KiB
Plaintext
---
|
|
title: Files & Volumes
|
|
description: Browse and safely edit the config files inside a stack's mounted volumes, plus the files in the stack's own directory, from the dashboard.
|
|
---
|
|
|
|
Files & Volumes gives you direct access to the files your containers actually read at runtime: the configuration inside a stack's **mounted volumes** (bind mounts and named Docker volumes), as well as the files in the stack's own source directory. A typical use is editing the Nginx and proxy configuration inside a reverse proxy's `/config` volume without leaving the dashboard. It lives on the **Files & Volumes** tab inside the stack editor, alongside the dedicated `compose.yaml` and `.env` editors.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/overview.png" alt="Files & Volumes tab open with the root switcher and a populated tree on the left and a config file open in the editor on the right" />
|
|
</Frame>
|
|
|
|
<Note>
|
|
Browsing is limited to the roots the stack itself declares: its source directory and the volumes mounted by its services. You cannot browse other stacks or arbitrary locations on the host.
|
|
</Note>
|
|
|
|
## Opening Files & Volumes
|
|
|
|
1. Click any stack in the left sidebar.
|
|
2. Click **edit** in the right-hand Anatomy panel header to open the editor.
|
|
3. Switch to the **Files & Volumes** tab.
|
|
|
|
The **files** shortcut button next to **edit** in the Anatomy header opens the editor and selects the Files & Volumes tab in one click.
|
|
|
|
Files & Volumes is available on every Sencho tier. Read actions (browse, preview, download, inspect permissions) require **stack read** permission, which every signed-in role has by default. Write actions (upload, edit, create, rename, move, change permissions, delete) require **stack edit** permission on your account.
|
|
|
|
## File roots: Volumes and stack source
|
|
|
|
The left pane opens with a **Browsing** selector that lists the roots Sencho discovered for the stack, grouped into **Volumes** and **Stack source**. When the stack declares at least one browsable volume, the explorer defaults to it; otherwise it opens on the stack source.
|
|
|
|
Each volume root is labelled by its container path (for example `/config`) and the type of mount behind it:
|
|
|
|
- **Bind mounts** map a host directory into a service (for example `./config:/config`). When the directory is reachable by Sencho, the root is fully browsable and editable.
|
|
- **Named volumes** are Docker-managed volumes. Sencho browses and edits them through a short-lived, locked-down helper container, so they work even though their on-disk location is not directly visible to the dashboard.
|
|
|
|
The same source mounted by more than one service is shown as a single root, summarised as `N mounts`. A root that any service mounts read/write is editable; a root that every service mounts read-only is browse-only.
|
|
|
|
<Note>
|
|
Editing a config file does not restart the service that reads it. After you save, restart the relevant service so it picks up the new content.
|
|
</Note>
|
|
|
|
### When a volume cannot be browsed
|
|
|
|
A volume root is shown with a short explanation and is not browsable when:
|
|
|
|
- the bind mount points at a host path Sencho cannot reach (mount that path into the Sencho container to browse it),
|
|
- the mount targets a protected host location such as `/`, `/etc`, `/proc`, `/sys`, `/dev`, or the Docker socket,
|
|
- the mount overlaps Sencho's own managed stack area (browse the owning stack's source instead), or
|
|
- a named volume cannot be resolved on the node that owns the stack.
|
|
|
|
### Named-volume editing details
|
|
|
|
Named-volume editing is best-effort and bound by file ownership. The helper container writes as an unprivileged user, so a file owned by `root` or a specific application user may not be writable; Sencho returns a clear permission error in that case. New files created in a named volume are owned by the helper user, while edits to an existing file keep that file's owner and mode. Named-volume saves are written in place and are not atomic, so a save interrupted mid-write can leave the file partially written; the files involved are small config files, which keeps the window tiny.
|
|
|
|
## Layout
|
|
|
|
The Files & Volumes tab splits into two panes. The left pane holds the Browsing selector, the upload affordance, the new-folder button, and the directory tree for the selected root. The right pane is the action bar plus the file viewer.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/layout-panes.png" alt="Files tab two-pane layout showing the upload widget and tree on the left and the file viewer on the right" />
|
|
</Frame>
|
|
|
|
## Browsing the directory tree
|
|
|
|
Folders sort before files, and entries within each group sort alphabetically.
|
|
|
|
Click a folder to expand or collapse it. Click a file to open it in the viewer on the right. Symlinks render with a chain icon and behave like files when clicked. Deleting a symlink removes only the link entry; the file it points to is untouched.
|
|
|
|
**Display cap.** Each directory render is capped at 1000 entries. A folder with more than 1000 children shows the first 1000 alphabetically with a footer noting how many entries the directory holds in total. The tree also has a filter input at the top of the list so you can narrow a large directory to the entries you care about without dropping to a shell.
|
|
|
|
## Protected files
|
|
|
|
Protection applies to the **Stack source** root. On a volume root a file named `compose.yaml` or `.env` is an ordinary config file: it opens directly in the viewer and has no delete restriction, because it is the application's own file rather than the stack's compose definition.
|
|
|
|
On the stack source root, the amber dot in the tree marks the five canonical stack files: `compose.yaml`, `compose.yml`, `docker-compose.yaml`, `docker-compose.yml`, and `.env`.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/protected-tree-marker.png" alt="File tree with amber dot markers next to compose.yaml and .env" />
|
|
</Frame>
|
|
|
|
Two behaviours follow from the marker:
|
|
|
|
- **Dedicated tab redirect.** Clicking `compose.yaml`, `compose.yml`, or `.env` jumps you to the matching **compose.yaml** or **.env** tab so the save-and-deploy controls stay in front of you. `docker-compose.yaml` and `docker-compose.yml` are still flagged as protected, but they open in the regular file viewer because they are not the canonical Sencho file.
|
|
- **Delete is blocked at the stack root.** The five canonical files at the stack root cannot be deleted through the explorer: the delete is rejected. Remove the whole stack via Stack Actions instead. A same-named file nested in a subdirectory is an ordinary file and can be deleted after the type-to-confirm step.
|
|
|
|
## Viewing files
|
|
|
|
When you click a text file, its contents appear in the editor on the right. The Monaco editor auto-detects the language from the extension.
|
|
|
|
| File type | Behaviour |
|
|
|-----------|-----------|
|
|
| Text file up to 2 MB | Rendered inline with syntax highlighting. |
|
|
| Text file over 2 MB | Panel with the filename, size, and a **Download** button. |
|
|
| Binary file | Same panel layout, label is `Binary file`. |
|
|
|
|
## Editing and saving
|
|
|
|
When you have stack edit permission, the editor opens in write mode. The toolbar shows the filename and a **Save** button that activates as soon as there are unsaved changes.
|
|
|
|
When you do not, the toolbar shows a `Read-only` chip and the editor refuses input.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/viewer-edit-mode.png" alt="Viewer toolbar showing the filename label and the Save button next to a YAML buffer" />
|
|
</Frame>
|
|
|
|
Click **Save** to write the file to disk. If you have unsaved edits and click a different file in the tree, a confirmation dialog asks whether to discard them; cancelling keeps you on the current file.
|
|
|
|
Saves use optimistic concurrency: the editor remembers when the file was last loaded, and a save that targets a stale version returns a "file changed elsewhere" notice with the current server-side content. Your typed buffer is preserved so you can review the new version and reapply your edits before saving again.
|
|
|
|
Writes are atomic at the filesystem level. Sencho stages the new content into a sibling temporary file, fsyncs, and promotes it via rename, so a crash or power loss never leaves a half-written target on disk.
|
|
|
|
<Warning>
|
|
Editing a file does not restart any containers. If your stack reads the file at runtime (for example, a config file mounted as a volume), restart the relevant service after saving so the container picks up the new content.
|
|
</Warning>
|
|
|
|
## Creating files and folders
|
|
|
|
The toolbar **New folder** button at the top of the tree creates a folder in the currently selected directory (the parent of the file you have open, or the stack root if nothing is open).
|
|
|
|
Right-click any folder for **New File** and **New Folder** entries that scope to the right-clicked folder. These write controls appear only when your account has stack edit permission.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/new-file-dialog.png" alt="New file modal scoped to the nginx folder, with the file name field populated and a Create button" />
|
|
</Frame>
|
|
|
|
Filenames cannot be empty, cannot contain `/` or `\`, and cannot be `.` or `..`. The Create button stays disabled until the input passes validation.
|
|
|
|
## Uploading files
|
|
|
|
The dashed **Upload file** affordance at the top of the tree opens a file picker. You can also drag and drop a file onto the dashed zone; the border lights up in the brand colour when a file is hovered over a valid drop target. Uploads are one file at a time.
|
|
|
|
| Limit | Value |
|
|
|-------|-------|
|
|
| Maximum file size | 25 MB. Uploads above the limit return a 413 error with `TOO_LARGE`. |
|
|
| Target directory | The currently selected directory, or the stack root if no file is open. |
|
|
| Same-name files | A confirmation dialog asks whether to replace the existing file. Cancelling keeps the original. |
|
|
|
|
The upload affordance is hidden for users without stack edit permission.
|
|
|
|
<Tip>
|
|
For bulk transfers or files above 25 MB, use `scp` or `rsync` from your workstation directly to the stack directory on the host.
|
|
</Tip>
|
|
|
|
## Downloading files
|
|
|
|
When a file is selected, the right pane action bar shows **Download**. Files stream straight to your browser. Files that exceed the inline preview limit also expose a Download button inside the oversized-file panel itself.
|
|
|
|
## Renaming
|
|
|
|
Right-click any file or folder and choose **Rename**. The dialog accepts a new name following the same rules as creation. Rename keeps the entry in its current folder.
|
|
|
|
Rename appears only when your account has stack edit permission.
|
|
|
|
## Moving
|
|
|
|
Move a file or folder into a different directory in one of two ways:
|
|
|
|
- **Move to…** Right-click the entry and choose **Move to…**. The dialog shows the stack's folder tree; pick a destination folder (or **Stack root**) and choose **Move**. Destinations that would collide or make no sense (the entry's current folder, a folder inside the entry itself, or a name that is reserved at the stack root) are not selectable.
|
|
- **Drag and drop.** Drag the entry onto a folder in the tree, or onto empty space to move it to the stack root.
|
|
|
|
Moving requires stack edit permission. The protected stack files (compose / docker-compose / `.env`) at the stack root stay put: the compose CLI reads them from the stack directory, so they are not offered as move sources or root destinations. Moving a file changes only where it lives on disk; it does not redeploy or restart the stack.
|
|
|
|
## Permissions (chmod)
|
|
|
|
Right-click any file and choose **Permissions** to inspect or edit its Unix mode bits. The dialog shows a 3 by 3 grid of `r` / `w` / `x` toggles for Owner, Group, and Other, plus the current octal value.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/permissions-dialog.png" alt="Permissions modal for a file showing the rwx grid for Owner, Group, and Other plus the octal value 644" />
|
|
</Frame>
|
|
|
|
When your account has stack edit permission, the toggles are interactive and the footer adds **Save**. For viewer accounts the dialog opens read-only: the toggles render the current state and the footer shows only **Close**.
|
|
|
|
<Note>
|
|
Permissions are applied with `chmod`. Permission changes on symlinks are not supported; edit the target file's permissions directly.
|
|
</Note>
|
|
|
|
## Deleting
|
|
|
|
There are three delete entry points. All three require stack edit permission, and all three open the same confirmation modal.
|
|
|
|
- **Toolbar delete.** With a file open in the viewer, click **Delete** in the right-pane action bar.
|
|
- **Context-menu delete.** Right-click any file or folder in the tree and choose **Delete**.
|
|
- **Non-empty folder delete.** The first attempt is non-recursive. If the folder has contents, the modal switches to `This folder is not empty. Delete everything inside?` with a destructive **Delete all** button.
|
|
|
|
When the entry is one of the five protected names, the modal asks you to type the filename before the destructive button activates.
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/delete-protected-confirm.png" alt="Delete confirmation modal for compose.yaml requiring the user to type the filename before the destructive button activates" />
|
|
</Frame>
|
|
|
|
<Warning>
|
|
Deletes are permanent. Sencho does not keep a trash bin or undo history for file operations.
|
|
</Warning>
|
|
|
|
## Context menu reference
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/context-menu-folder.png" alt="Right-click menu on a folder showing New File, New Folder, Rename, and Delete entries" />
|
|
</Frame>
|
|
|
|
<Frame>
|
|
<img src="/images/stack-file-explorer/context-menu-file.png" alt="Right-click menu on a file showing Rename, Permissions, and Delete entries" />
|
|
</Frame>
|
|
|
|
| Right-click target | Admin entries (with stack edit) | Viewer entries |
|
|
|---|---|---|
|
|
| Folder | New File, New Folder, Rename, Move to…, Delete | No write entries |
|
|
| File | Rename, Move to…, Permissions, Delete | Permissions (read-only) |
|
|
|
|
**Move to…** is absent for the protected stack files (compose / docker-compose / `.env`) at the stack root, which cannot be moved out of the stack directory.
|
|
|
|
The Permissions dialog opens for everyone; only users with stack edit permission can save changes.
|
|
|
|
## Troubleshooting
|
|
|
|
<AccordionGroup>
|
|
<Accordion title="Files & Volumes tab is empty or returns a 403">
|
|
The signed-in role lacks **stack read** permission for this stack. Ask an admin to grant the permission on your account, or sign in with a role that already has it.
|
|
</Accordion>
|
|
<Accordion title="No browsable stack volumes detected">
|
|
The stack declares no volume Sencho can reach, so the explorer opens on the stack source. This happens when the stack uses only anonymous or `tmpfs` mounts, when its bind mounts point at host paths that are not mounted into the Sencho container, or when its named volumes have not been created yet. Deploy the stack so its named volumes exist, or mount the relevant host path into the Sencho container, then reopen the tab.
|
|
</Accordion>
|
|
<Accordion title="A volume is shown but cannot be browsed">
|
|
The root carries a short explanation. A bind mount to a host path Sencho cannot reach needs that path mounted into the Sencho container. A mount that targets a protected host location (`/`, `/etc`, `/proc`, `/sys`, `/dev`, the Docker socket) or that overlaps Sencho's managed stack area is intentionally not browsable. A named volume that cannot be resolved on the owning node is not browsable until it exists.
|
|
</Accordion>
|
|
<Accordion title="Saving a file in a named volume returns a permission error">
|
|
Sencho writes to named volumes as an unprivileged helper user. A file owned by `root` or a specific application user may not be writable by that helper. Adjust the file's ownership or permissions on the host, or edit the file from a context that owns it, then try again.
|
|
</Accordion>
|
|
<Accordion title="A volume is read-only">
|
|
Every service that mounts the volume declares it read-only (for example `./config:/config:ro`). The explorer browses it but disables the edit, upload, delete, and rename controls. Change the mount to read/write in the compose file and redeploy if you need to edit its contents from Sencho.
|
|
</Accordion>
|
|
<Accordion title="Cannot delete compose.yaml or .env">
|
|
The five canonical stack files (`compose.yaml`, `compose.yml`, `docker-compose.yaml`, `docker-compose.yml`, `.env`) are protected because removing them mid-life breaks the stack. To delete a stack entirely, use **Delete stack** in the stack toolbar's overflow menu rather than removing these files individually.
|
|
</Accordion>
|
|
<Accordion title="Save returns 'file changed elsewhere'">
|
|
Another writer (a teammate, a deploy hook, or an out-of-band edit on the host) saved the file after you loaded it. Use the diff to compare your edits against the current version, then save again. Your typed buffer is kept so you do not have to retype your changes.
|
|
</Accordion>
|
|
<Accordion title="Upload returns DISK_FULL">
|
|
The disk hosting the stack's compose directory has no free space. Check the volume mounted as `COMPOSE_DIR` (defaults to `/app/compose` inside the Sencho container) and free up space, or move the volume to a larger disk.
|
|
</Accordion>
|
|
<Accordion title="File shows as 'Binary file detected' but it is a text file">
|
|
The binary detection heuristic flagged null bytes or a high proportion of non-printable characters in the file's first kilobytes. This can happen with certain encodings, non-UTF-8 byte sequences, or unusual line-ending mixes. Click **Open as text anyway** on the binary panel to re-fetch the file as UTF-8 text and edit it in the inline viewer. Files above the 2 MB preview limit still need a Download.
|
|
</Accordion>
|
|
<Accordion title="Upload fails with a 413 error">
|
|
The file exceeds the 25 MB per-file upload limit. Compress or split the file before uploading, or transfer it via `scp` or `rsync` directly to the stack directory on the host.
|
|
</Accordion>
|
|
<Accordion title="Cannot delete a folder">
|
|
The first delete attempt is non-recursive. If the folder is not empty, the dialog switches to `This folder is not empty. Delete everything inside?`. Click **Delete all** to remove the folder and its contents. If the error persists, check whether a running container has an open file handle inside that directory; stop the relevant service and retry.
|
|
</Accordion>
|
|
<Accordion title="File saved but the container still reads the old content">
|
|
The container caches the file at startup, or the mount is configured read-only inside the container. Restart the service after saving so the container picks up the new file.
|
|
</Accordion>
|
|
<Accordion title="Download button is missing">
|
|
The Download button appears in the right-pane action bar only when a file is selected in the tree. Click any text or binary file to open it, and the button activates.
|
|
</Accordion>
|
|
<Accordion title="A large directory shows a 'N total entries' footer">
|
|
Each directory render is capped at 1000 entries to keep the tree responsive. Use the filter input above the tree to narrow the list, or drop into a host shell with `cd` into the stack directory if you need to work with entries past the cap.
|
|
</Accordion>
|
|
<Accordion title="Write controls are missing">
|
|
Upload, create, rename, move, chmod save, and delete require **stack edit** permission. Viewer accounts can browse, preview text files, and inspect permissions in read-only mode.
|
|
</Accordion>
|
|
</AccordionGroup>
|