LinShare replaces email attachments with a service you host, and audits every download

A file exchange service aimed at organisations, not at sharing photos

LinShare is described as an open source file sharing platform built for organizations that need to exchange documents with internal and external collaborators while keeping full control over privacy and traceability. The README states plainly what it replaces: email attachments, USB sticks and consumer cloud drives, with a self-hosted service you run on your own infrastructure.

That framing explains the feature list, which is all about organisational mechanics rather than consumer convenience. There is a personal space where you upload, version and organise your files and then share them by link or email. There are shared spaces, which are workgroups with roles, nested folders and shared drives for teams. There are upload requests, which ask external people to send you files through a secure, expiring drop box. There are guests, invited external users with restricted, time-limited accounts. And there are contact lists, so you can reuse groups of recipients for recurring shares.

The feature that says most about the audience is the audit one. Activity logs and audit means every download, share and change is traced. For a company moving documents between a contractor and a legal team, that record is the reason to run your own file service rather than sending a link to a public drive.

The primary language of the repository is listed as Shell, the licence is AGPL-3.0, the homepage is linshare.app, and the README is available in English and in French.

Enterprise integration is where the bulk of the complexity lives

The enterprise integration line in the feature list is dense and it is the part that determines whether LinShare fits your organisation.

There is LDAP directories, LemonLDAP::NG and Microsoft Azure SSO through OpenID Connect, and JWT. There is antivirus scanning and file previews. There is a REST API, described as letting you automate everything from your own tools. And then there is an MCP server, in a separate repository, which lets any MCP-compatible assistant manage files, shares, guests and workgroups on your behalf.

The SSO story is worth reading more carefully, because the install section lists three separate guides: LemonLDAP::NG using headers, LemonLDAP::NG using OIDC with opaque tokens, and Microsoft Azure using OIDC with JWT tokens. Three guides means three different identity topologies, which in turn means the deployment carries one of three authentication designs rather than a single portable one.

The MCP server is the newest-looking piece. Wrapping an MCP-compatible assistant around file management, shares, guests and workgroups is a way of saying the API surface is complete enough to be driven conversationally, and it is a sign of where the project thinks the interaction is heading.

The REST API, by contrast, is the safe bet. If you want to script against LinShare, that is the documented surface, and it is the one that will still be there when the assistant integration changes.

The stack is Java, Tomcat and two databases

The installation table makes the deployment shape clear, because the compatibility matrix row lists what you need before anything else: OS, JVM, PostgreSQL, MongoDB, Tomcat, Apache.

So LinShare is a WAR based application deployed behind Apache, talking to PostgreSQL for the relational data and MongoDB for the document and index side. There is no single image to pull. The release packages are WAR files, UI bundles and SQL scripts, published at download.linshare.org/versions/.

The install guides are per distribution. There is a Debian 12 guide for LinShare 6.x, a Debian guide for older releases, and a CentOS 7 guide. The CentOS 7 entry is worth noticing for what it implies about the deployment matrix the project maintains, since CentOS 7 is long past its own support window, so that guide is a legacy path rather than a recommendation.

You can also fetch every component of a release with Maven from the repository itself.

mvn dependency:copy-dependencies -DoutputDirectory='linshare'

The repository is a Maven project with a pom.xml at the top level, a .gitlab-ci.yml and a .gitlab/ directory, so the build and test pipeline runs on GitLab rather than GitHub Actions, and the CHANGELOG.md carries per-component changelogs for every version.

The license situation is the usual one for this kind of project, with both a LICENSE and a LICENSE.md in the repository root.

Running the whole thing locally with Docker Compose

For evaluation rather than production, there is a much faster route, and it lives in a separate repository.

The linshare-docker repository ships a docker-compose stack with the server, both web interfaces, PostgreSQL, MongoDB, a sample LDAP directory, ClamAV, a thumbnail server and a test SMTP relay.

git clone https://github.com/linagora/linshare-docker.git
cd linshare-docker
docker-compose up -d

Then you open https://linshare.local, with the /etc/hosts entries described in that repository's README.

That stack is unusually complete for a demo, and it is complete on purpose. A sample LDAP directory means you can exercise the single sign-on path without wiring a real directory, a test SMTP relay means you can trigger the upload request and guest flows without sending real mail, and ClamAV means the antivirus scanning feature is actually running rather than stubbed. If you are deciding whether LinShare handles your process, this is the environment to find out.

The two web interfaces in the stack are also worth noticing. LinShare has a user interface for the people sharing files and a separate administration interface, and the stack runs both, so an evaluation covers the admin side as well as the user side.

The public demo, and the account types it exposes

There is a public instance at demo.linshare.org running the latest LinShare release, and the README says it is reset and updated on a regular basis.

The demo enumerates its accounts, which is unusual and useful, because the account types map directly onto the features. There are internal users with a shared password, external recipients who are email addresses without a LinShare account, and guest candidates, which are external addresses you can turn into guest accounts.

Those three categories are the feature model in miniature. A share to an external recipient uses no account at all. A guest account is a restricted, time-limited account that can be given narrowly scoped access, and in 6.5.4 guests gained the ability to share through contact lists, with the public contact lists of their source domain becoming usable as recipients when no list is assigned to the guest.

The demo also uses a separate webmail instance, because emails are only delivered to linshare.org addresses, and reading them means visiting the demo webmail rather than a real inbox. That is a small implementation detail with a large lesson for anyone planning a deployment: if LinShare is going to send invitations and upload request notifications, you need working outbound mail and the demo assumes a separate mail system rather than a shared domain.

It also demonstrates that the tool sends real email, which is a deployment consideration for anyone with strict outbound mail policies.

Version 6.5.4 changed guest sharing, and there is an upgrade guide for it

The What's new section names one release, LinShare 6.5.4 from July 2026, and lists three things.

Guest accounts can now share through contact lists, and when no list is assigned to the guest, the public contact lists of its source domain become usable as recipients. There is a fixed anonymous share error when a restricted guest shares through a contact list. And for anyone upgrading from 6.5.3, there is an upgrade guide at documentation/EN/upgrade/linshare-upgrade-from-v6.5.3-to-v6.5.4.md.

That third item is the useful one for an operator, because it tells you the project treats patch level upgrades as something that can need a document. The behaviour around guest sharing and contact lists has changed, and a guide exists for it, which is what you want from a platform that holds your audit trail.

The full release notes for every version, with per-component changelogs, are in CHANGELOG.md in the repository root. Per-component matters here, because LinShare is a server with several moving parts, the web interface, the administration interface, and the external components, and a change in one of them is what you need to read about when something in the interface behaves differently.

On maintenance, the repository is not archived and the last push was on 2026-10-08, so work is landing on master. There are no GitHub releases, but the README carries a release badge pointing at the repository tags, which is where the versioned artefacts live.

Where LinShare is the wrong choice

Three cases stand out, and they are not close calls.

The first is a small team that needs to send large files occasionally. LinShare brings a JVM, Tomcat, Apache, PostgreSQL, MongoDB, a directory integration, antivirus scanning and an audit system. If the requirement is a handful of shared files a month, that is a lot of infrastructure to run and secure, and a hosted drive with expiring links is the right size of tool. LinShare earns its weight when the volume and the audit requirement are both real.

The second is a team without the patience for a multi-service deployment. The docker-compose stack in the separate repository makes evaluation easy, but the production path is a WAR behind Apache with two databases and a directory, and the install guides are per distribution. The operational surface is genuinely large.

The third is a deployment where outbound email is restricted. Guest invitations, upload requests and contact list sharing all depend on sending mail, and the demo shows the design assumption of a working mail relay. If you cannot send mail from the instance, a large part of the external collaboration story does not function.

What LinShare is genuinely good for is the organisation that has already decided it cannot put confidential documents in a consumer drive, and needs the audit trail as much as the sharing. In that case the stack is the price of the trace.

Editorial conclusion

Adopt LinShare if you need a file exchange platform you operate yourself, with audit logs over every download and share, guest accounts for people outside the organisation, and directory integration for your existing identity system. Do not adopt it for a small team that could use a hosted drive, because the stack includes Tomcat, PostgreSQL, MongoDB, LDAP and antivirus, and the operational weight is real. Before you deploy, work through the compatibility matrix for your OS, JVM and database versions, and read the 6.5.3 to 6.5.4 upgrade guide if you are running the previous release, since the recent change touches guest sharing through contact lists.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. linagora/linshare on GitHub
4. Project website
5. README