Cockpit Navigator turns Cockpit into a full file manager

A file manager inside the admin console you already open

Cockpit Navigator is a file system browser for Cockpit: remotely browse, manage, edit, upload and download files on your server through your web browser.

The positioning is the point. Cockpit is a web-based server administration interface, and the standard advice for doing something unusual in it is to open a terminal inside the panel. Cockpit Navigator removes that step for file operations by adding a navigator to the same interface.

The feature list covers the operations an administrator actually performs. You can browse the entire filesystem, create, delete and rename files, edit file contents, and edit file ownership and permissions. You can create symbolic links to files and directories, and reorganize files through cut, copy and paste.

Two of them are highlighted in the documentation as the things that make it more than a listing. Upload files by dragging and dropping, and download files and directories.

The directory download is the one that a plain file browser in a web panel usually gets wrong, and having it here means the plugin is aimed at moving a data set onto or off a server rather than at editing a config file. Drag and drop upload is the mirror of that.

The editing of ownership and permissions is the third thing worth noticing. That is the operation that most often sends an administrator to the command line, and it is here because the plugin has a server-side component with the privileges to do it, rather than being a pure client-side viewer over an existing API.

Installing it as a package on Ubuntu, EL7 or EL8

The primary install route is a prebuilt package, and the documentation gives the exact commands per distribution family.

On Ubuntu the package is fetched with wget and installed with apt:

$ wget https://github.com/45Drives/cockpit-navigator/releases/download/v0.5.10/cockpit-navigator_0.5.10-1focal_all.deb

# apt install ./cockpit-navigator_0.5.10-1focal_all.deb

On EL7 the equivalent is a yum install of the noarch rpm, and on EL8 it is the same with dnf. The URLs follow the same pattern with the distribution in the filename, and the documentation pins them to version 0.5.10, which it also describes as the latest, even though the release history shows newer tags such as v0.5.14-1 and v0.5.13-3.

That mismatch is worth noting before you plan an install. The documented commands are one release line behind the newest tags, and the maintainers publish separately versioned artifacts for focal, el7 and el8, so the filename has to match your distribution exactly.

The release tags themselves are also interesting, because they carry a packaging revision after the version. v0.5.13-2, v0.5.13-3 and v0.5.14-1 are three tags published in July 2026, two of them on the same day. That is a rebuild of the same upstream version with a new package revision, which is how a change to packaging or to a bundled dependency ships without a version bump in the plugin itself.

Building from source needs four dependencies and a make install

The from-source route is for people who want a specific tag or need to patch it, and it is short.

First, ensure the dependencies are installed: `cockpit`, `python3`, `rsync` and `zip`. The `cockpit` dependency is the plugin host, and the other three are what the plugin itself needs at runtime, with rsync and zip being what make directories downloadable as an archive.

Then:

$ git clone https://github.com/45Drives/cockpit-navigator.git
$ cd cockpit-navigator
$ git checkout <version>

and the install step is a single command:

# make install

The `git checkout <version>` step is there for a reason, since the plugin is tagged and the default branch will move. The makefile at the repository root is what the install target belongs to.

The repository layout explains the rest. There is a navigator/ directory for the plugin itself, a packaging/ directory for the distribution packaging, a doc/ directory holding the screenshots referenced in the README, a manifest.json for the Cockpit plugin metadata, a CHANGELOG.md and a LICENSE.

The primary language is JavaScript, which is what you would expect for a Cockpit plugin, since Cockpit's own interface is a web application and a plugin that looks native in the panel is written the same way.

The 45Drives repository route handles GPG keys and package lists

The third install route is a 45Drives package repository, and it comes in two forms, an automatic script and a manual sequence.

The automatic one is a two-liner:

curl -sSL https://repo.45drives.com/setup -o setup-repo.sh
sudo bash setup-repo.sh

After that, on Ubuntu it is `sudo apt install cockpit-navigator`, and on EL7 or EL8 it is `sudo dnf install cockpit-navigator`.

The manual route is the more interesting one, because it shows what a package repository setup actually involves, and the EL7 case is where the differences show.

On Ubuntu the steps are to import the GPG key, which pipes the ASCII key through gpg --dearmor into a keyring under /usr/share/keyrings, then to add the 45drives.sources file into /etc/apt/sources.list.d with curl and run apt update, and then install the package.

On EL7 the 45drives.repo file is downloaded into /etc/yum.repos.d, and then there is an extra step: a sed command rewrites el8 to el7 and EL8 to EL7 in the repo file. In other words, the EL7 and EL8 repositories are served as the same file and the client rewrites the distribution identifiers. After that comes yum clean all and the install.

The EL8 route is the same download without the sed, followed by dnf clean all and the dnf install.

The repository URL is a 45Drives-operated one, so this route ties the install to that vendor's infrastructure, which is a different dependency from the GitHub release packages that carry everything with them.

Where this sits against the other ways to manage files on a server

The comparison is really between three approaches, and Cockpit Navigator is the middle one.

SSH with a terminal tool is the baseline. It works everywhere, it is scriptable, and it is what most people use. Its cost is that it is a separate context from the admin panel, so a routine job of checking a disk usage, fixing an ownership and reading a log becomes three different interfaces.

A dedicated web file manager as its own application, something like a self-hosted file manager, is the other end. It is a full application with its own authentication, its own attack surface, its own upgrade cycle, and its own memory and CPU cost on a server. On a machine where you already run Cockpit, that is a second thing to install, secure and maintain for a job that is a sidebar away from where you already are.

Cockpit Navigator is a plugin, and plugins inherit their host's authentication and session. That is the structural argument in its favour: it is not another login, it is another tab.

The honest limitation is that a browser file manager is a worse interface than a terminal for anything repetitive. Moving two hundred files, or scripting a transformation across a directory, is what a shell is for, and a plugin that tries to replace that ends up being a worse shell. The plugin is at its best on the operations that are one-off and visual: checking permissions, reading a file, fixing an owner, grabbing a directory as an archive.

There is also a scope limit worth stating. The documentation says you can browse the entire filesystem, which means the plugin's power is bounded by the privileges of the Cockpit session it runs under. Anyone who can reach the Cockpit panel can reach the filesystem as the Cockpit service account can, and anyone with root access to the host can reach everything. That is the same privilege model as the rest of Cockpit, and it is the reason Cockpit itself is normally not exposed beyond an SSH tunnel or a VPN.

Editorial conclusion

Adopt Cockpit Navigator if you administer servers through Cockpit and want file operations in the same tab as storage, networking and logs, rather than switching to SSH for every file operation. Skip it if your fleet is managed by configuration management rather than by hand, since a browser file manager does not fit that workflow, or if the machine does not already run Cockpit. Verify first that the Cockpit package is installed on the target, that the python3, rsync and zip dependencies are present if you build from source, and that the release you install matches your distribution, since the documented package URLs are pinned to version 0.5.10 while newer tags exist.

Frequently asked questions

Official sources

1. 45Drives/cockpit-navigator on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases