FileZilla Server Permissions: Give a Partner One Folder

Posted in Uncategorized

When a partner, a customer or a supplier needs to exchange files with you, the quickest setup is also the riskiest one: a single shared account that can see the whole drive. It works until someone deletes the wrong folder, or until you realize that a contractor from two years ago can still read everything. In the logs guide we looked at spotting activity that doesn’t match an account. The better fix is upstream: give every partner an account that can only reach what it needs.

FileZilla Server and FileZilla Pro Enterprise Server (FZPES) are built for this. You create a user, mount one folder as that user’s whole world, choose what they may do inside it, and optionally limit where they can connect from. This guide walks through the setup in the order we’d do it. It is about the server side: if you’re looking for how to connect from a client, that’s a different guide.

1. Understand the model: users, mount points, permissions

Three ideas do most of the work. A user is an account that can log in. A mount point links a native path (a real folder on the server) to a virtual path (what the user sees). And each mount point carries permissions. A user can only reach the files exposed through their mount points; anything not mounted doesn’t exist as far as that user is concerned. Our mount points guide covers the details.

This is a better starting point than relying on file system permissions alone, because you can say “this partner sees only this folder” in one place, without moving anything around on disk.

2. Create a dedicated user

Open Rights management › Users and click Add at the bottom of the list on the left (our guide to creating a user has the full screen-by-screen detail). Give each partner their own account, named after the partner, rather than reusing one login for everyone. When something goes wrong, or when a relationship ends, you’ll know exactly which account to look at.

New users default to Require a password to log in, which is the right choice for most partners; just share the password through a secure channel. Avoid Do not require authentication for anything beyond a deliberate public drop. In FZPES, you can add public key authentication for SFTP and a second factor (2FA) on top of a password.

The special <system user> and <ad user> entries are disabled by default, so no users are active at installation. Keep them disabled unless you actually need system or Active Directory logins.

3. Mount one folder as the partner’s root

On the user’s General tab, under Mount points, add a single entry:

• Virtual path: /, the root the partner sees as soon as they connect.
• Native path: the partner’s own folder on the server, for example D:\partners\acme.

The folder’s contents then appear directly at the root, so the partner sees the files and subfolders inside it, with no sign of the rest of the drive. If the folder doesn’t exist yet, tick Create native directory if it doesn’t exist.

If you add many partners, placeholders save time. In a native path, %<user> is replaced with the name of the logged-in user, so one mount point such as D:\partners\%<user> can serve every partner, each landing in a folder named after their account. Try it with a test account before relying on it.

4. Choose what they’re allowed to do

Each mount point has one of four permission settings:

• Read only: the partner can list and download, but can’t change files or the directory structure. Good for distributing reports.
• Read + Write: any modification is allowed. If you deselect Writable directory structure, they can still work with files but can’t create, delete or rename subdirectories.
• Write only: files can be uploaded, but not read or listed. This is the classic drop box: a partner can send you a file and can’t browse what anyone else sent.
• Disabled: blocks a directory even when its parent is accessible through another mount point. To keep /Documents/disabled private while /Documents stays shared, add a second mount point for the subfolder and set it to Disabled.

By default, permissions apply to all subdirectories. Deselect Apply permissions to subdirectories if you want only the top level exposed. Remember that the file system’s own permissions still apply on top: if a file is read-only on disk, a Read + Write mount point won’t make it writable.

5. Use a group when partners share the same rules

If ten partners should all get the same limits and restrictions, set them once on a group instead of ten users. Groups can define mount points, filters and limits, and you assign a user with the Member of groups menu (see how to add a user to a group).

One thing to know before you rely on groups: if the same virtual path is defined at several levels, a mount point set on the user wins over the group’s. If a user belongs to more than one group, the group listed first wins, so the order matters. For a one-person exception, define a mount point on that user.

6. Add IP filters and limits

Permissions decide what a partner can do; IP filters decide where they can connect from. On a user or group, open the Filters tab and add the partner’s address or range to the Allowed IP ranges. Two details are worth remembering: a protocol-level filter overrides a conflicting user or group filter, and an address that appears in both the allowed and the disallowed lists is allowed. If both lists are empty, no filtering is applied.

The limits tab lets you cap upload and download speed per session or across all sessions, and set a maximum number of concurrent sessions. A partner whose script opens fifty connections shouldn’t be able to starve everyone else.

7. Test it as the partner, then review it regularly

Before you send the credentials, log in as the new user from a client and check three things: you see only the intended folder, you can do what the permissions allow, and you can’t do anything else. Try uploading, deleting and creating a folder, and confirm each result matches what you set.

After that, access control needs maintenance. When a partnership ends or a contractor leaves, disable the user: clear User is enabled on the General tab, and if they are connected at that moment, their session is terminated immediately. Disabling is also easier to undo than deleting if you turn out to need the account again. Then keep an eye on activity, as described in what to look for in your FileZilla Server logs. And if your server is reachable from the internet, make sure the connection itself is encrypted; setting up FTPS on FileZilla Server covers that.

Where FileZilla Pro Enterprise Server fits in

Both FileZilla Server and FileZilla Pro Enterprise Server support users, groups, mount points, permissions, IP filters, and limits. The commercial version additionally offers SFTP alongside FTP and FTPS, public key authentication, two-factor authentication, Active Directory integration, and priority support for teams that require these advanced features.