Foldr does not give outside people their own NTFS identity. Someone who opens a public link or a secure link has no account on your domain, so the file server is never asked what that person may read. The share is opened for them with an account you chose (the share’s service account, or the person who made the link), and Foldr’s own link controls decide what they can reach. The opening account’s rights on the file server limit what a link can reach, but your NTFS permissions are not checked for each recipient, and on some settings they are not checked for the sharer either (the table below says which).
This article sets out exactly how that works, so you can decide whether it suits a given share. For the full sharing reference see A technical guide to Foldr’s sharing features, and for the setup steps see How to enable sharing for users and Configuring and enabling secure links for users.
What an outside person gets
An outside person gets a short URL to one file or one folder. A public link needs no sign-in unless you add a password. A secure link is tied to named email addresses: each recipient is emailed (when email notifications are switched on) and, if they do not yet have a password, guided through creating one before they can open it. You can limit who may create links to particular users or groups. People who receive a public link or a secure link do not take a seat, on any plan.
The link points at the item the sharer chose. A recipient cannot step outside that folder by editing the URL; Foldr refuses any path that resolves outside the link’s own folder.
Whose credentials open the file server
This is set per share, on the share’s Access tab, by the setting The service account is used for. It has three values.
| Setting | Opening a link on an SMB share | What limits the link |
|---|---|---|
| All access (browsing, links, crawls and jobs) | The service account opens the share. | The account’s rights on the file server. With NTFS permissions (ACL support) switched on for the share, Foldr also filters by the sharer’s permissions. With it off, nothing does. |
| Sharing and background work | Links, crawls and jobs use the service account. People still browse as themselves. | The account’s rights on the file server only. Foldr does not filter links by the sharer’s permissions on this setting. |
| Background work only | A link opens as the person who made it where that is possible. | When it opens as the sharer, the file server enforces the sharer’s own NTFS rights. When the service account is selected instead, the account’s rights apply. |
On Background work only, Foldr chooses the identity before it connects, in this order. It selects Kerberos delegation as the sharer if the share uses Kerberos. Otherwise it selects the sharer’s stored password, unless the directory has just refused it. Otherwise it selects the service account. This is a choice made up front, not a retry after a failed sign-in. If none of the three is available the link does not open, and the reason is written to the SMB log.
In every case the recipient is never the identity the file server sees. The file server sees the service account or the sharer.
What is checked when a link is made
- The sharer needs the Foldr permission to create the kind of link (public links, secure links, and the extra permission for uploads on secure links), granted on the share.
- Foldr reads the item’s metadata (its name, size and type) through the share. It does not test at that point that the sharer can read the file’s contents. On the first two settings a link can therefore offer a file the sharer could list but not open, if the service account can open it.
- Your governance rules, where you use them, can refuse an external link before it exists.
Foldr does not copy the sharer’s NTFS permissions onto the link. It records who made it and what it points at.
What is checked every time a link is opened
- The sharer must still exist and must still have read permission on the share in Foldr. If not, the link answers “not found”, the same as an expired or unknown link, and no connection to the file server is made. This is Foldr’s permission on the share, not a fresh check of the sharer’s NTFS rights, so removing someone’s NTFS rights on the file server does not by itself stop their links when a service account opens them.
- The link must not have expired, and a password or recipient sign-in must be satisfied.
- The path must sit inside the link’s own folder.
- For anything that changes files (an upload, for example), the sharer must still have write permission at that path in Foldr.
What the sharer controls
- Expiry. A date, or On download, which makes a one-time link. For outside recipients the first successful download spends it; a download by someone inside your organisation does not. An expire-on-download link is download-only.
- Password. A public link can carry a password. Foldr refuses weak ones. A link cannot have both a password and named recipients: use a password for an open link, or named recipients for a secure link.
- Named recipients (secure links). Each recipient is emailed when email notifications are switched on, and signs in with their own password. Only a recipient who has no password yet is taken through creating one.
- Uploads. Uploads need an administrator to allow them for that person (Allow uploads to secure links), and Foldr enforces that when uploads are switched on for a link. The sharer then switches uploads on for that folder. Files land in a folder named Foldr Uploads by default (an administrator can rename it) with a subfolder for each person, and the opening account needs write access on the file server.
- Deleting. An external user can never delete anything through a link.
- Removing. The sharer can switch a link off, and an administrator can remove any link from Shared Items. On shares where link changes need approval, some changes wait for an approver.
- Activity. Foldr’s activity log can record when a link’s files are opened, depending on how activity logging is set up. A public link has no named recipient, so it cannot say who opened it. The view count shown on a public link counts downloads, not page views.
Limits
- Outside people are not checked against NTFS one by one. If you need a different answer for each outsider, give each their own secure link to a different folder.
- A public link with no password is open to anyone who has the URL. Add a password, or use a secure link, for anything sensitive.
- Wherever the service account opens a link, it needs read access (and write access for uploads) to what you share. On Background work only, a link can open as its creator instead, so the account is needed only where it is the fallback.
- This article describes SMB shares. On cloud shares (SharePoint, OneDrive, Google Drive) which credentials open a link depends on the integration, so check the share’s Access tab.
- A link’s settings are kept in Foldr, not on the file server, so the file server’s own logs show the service account or the sharer, not the outside person.