Skip to main content
tinymash
  • Screen mode

Filesystem and permissions

Keep the hosting site definition, tinymash installation, and web document root distinct. A typical layout is:

/var/www/example/                  site definition
├── _auth/                         web-server authentication
├── logs/                          site and PHP-FPM logs
├── tmp/                           site-specific PHP temporary files
└── tinymash/                      tinymash installation
    └── public/                    web document root

Set the web document root to the installation's public/ directory. Configuration, content, users, drafts, plugin state, backups, and installation runtime files remain outside it. Host-owned paths in the site definition are not part of the tinymash installation or its deploy audit.

Writable paths

The PHP-FPM user needs write access to:

  • data/
  • users/
  • tmp/

Application source, dependencies, themes, plugins, and ordinary public assets should not require routine write access from PHP.

Run mutating CLI commands as the installation owner or the same service account used for normal maintenance. Do not run them as root; root-owned files can prevent later web writes. The CLI requires confirmation or --allow-root for mutating commands, but that override does not repair ownership mistakes.

Temporary directories

Give each installation its own writable temporary root. tinymash tries these locations in order:

  1. PHP's configured sys_temp_dir
  2. TMP
  3. TMPDIR
  4. TEMP
  5. the installation's tmp/ directory

Unavailable or symbolic-link paths are skipped. upload_tmp_dir remains PHP's upload-staging setting and is not used as a runtime cache fallback.

Runtime work uses private child directories. The web process records its selected root inside the installation so CLI commands run by the same operating-system user can find web-created import staging files. A CLI process running as another user ignores that record and uses its own PHP and environment settings.

After changing a pool's temporary path, reload PHP-FPM and make one normal request before testing the CLI. The request updates the path used by later CLI runs.

Path safety

Keep authoritative runtime paths as real directories inside the physical installation root. Do not replace content, users, media, temporary storage, third-party extension roots, or protected download storage with symbolic links to unrelated locations.

On hosts that use open_basedir, permit the complete physical tinymash installation root. Add only the explicit site-level paths PHP uses, such as a site-specific temporary directory or PHP log directory, plus required system paths. Do not replace the installation root with a manually maintained list of its child directories; that list is easy to make incomplete as features change. Nginx-only paths such as an HTTP Basic password directory do not need PHP access.

Store operational backups and transfer bundles outside public/. A web-server rule that blocks common archive extensions is a secondary safeguard, not permission to place private archives in the document root.

Capacity and ownership checks

Monitor free disk space and inode use for content, media, revisions, caches, imports, backups, logs, and static-export artifacts. A full filesystem can interrupt atomic writes even when PHP itself remains healthy.

After moving or restoring an installation, check ownership recursively before serving traffic. Then verify that the application can save content, upload media, write session data, run housekeeping, and create a backup without elevating privileges.