Who a script runs as

Every saved script has an owner: the person who saved it. When the script runs from an event, a schedule, a webhook, a form, a review or the action menu, it runs with that owner’s rights. This is what lets an ordinary user write an automation without being able to reach files they couldn’t open themselves.

There are two kinds of owner.

Elevated owners

A script runs elevated when its owner is:

• a built-in or system account (the appliance’s fadmin, for example), or
• anyone who may manage MaSH in Settings.

An elevated script isn’t held to a person’s file permissions. It can reach every share that Foldr itself can. It has the whole library.

Sandboxed owners

Every other owner is sandboxed. The script can do only what its owner could do by hand:

• Files. mash.files.get(share, path) opens the file as the owner, with the owner’s own credentials. If the owner can’t see a share, or the storage behind it refuses them, the script gets a permission error that names the share and the reason. A Windows file share (SMB) decides by its own file permissions, not Foldr’s.
• Writing and sharing. Writes, moves, deletes, field changes and sharing are checked against the owner’s permission for that action.
• Other scripts. mash.scripts reaches only scripts the owner owns. See Running one script from another.
• Events. mash.event.setShare can name only the owner as the share’s user.

A few parts of the library are closed to a sandboxed script. They fail with a permission error that says so:

Closed to a sandboxed script	Look up one thing instead
mash.users.all()	mash.user(name)
mash.groups.all()	mash.group(name)
mash.guardian.* (raw access control)	none: needs an elevated script
mash.sas.* (service accounts)	none: needs an elevated script

A script chain never gains rights. A sandboxed script that runs an administrator’s script with mash.scripts still runs that child sandboxed to the same person.

An exception that comes from the share

A share can be set to use its service account for all access. Everyone reaches such a share through the service account inside Foldr, so a sandboxed script does too. Foldr still makes its own permission check as the owner first.

Files handed to the script

Some runs start with a file already open, such as an event’s file. A sandboxed run never keeps a file that was opened as someone else. It reopens the file as its owner. So when person B uploads a file and person A’s script reacts, the script reads that file with A’s rights, not B’s.

Where each start picks its identity

Start	Runs as
Event, schedule	the script’s owner. A schedule reads its file list as the owner.
Webhook	the owner. The caller, if signed in, is mash.event.user.
File action menu	the owner when sandboxed. When the owner is elevated, the selected files open as the person who clicked. The person also needs Use Mashlet on the entry.
Form, sign, review	the owner of the script the form or rule names
By hand in the editor	no owner sandbox: the editor runs the text on screen directly, and it is open only to people who can manage MaSH. Its file and user come from the test file and test user you pick. The editor’s Virtual mode swaps in mock files and I/O, so a trial run touches nothing real.
mash.scripts	the child’s owner, never above the caller

Writing for both

If an administrator will write the script and ordinary users’ files will go through it, remember that it’s then elevated. It can touch files the triggering person can’t. Check the permissions you care about in the script. If you want the safer arrangement, save the script under an ordinary account.

A script that was fine when an administrator owned it can fail after it moves to an ordinary owner, because the owner can’t see a share. The run log will show a permission error that names the share.