Password-Protect a Directory in Plesk and Add Authorized Users

Plesk’s Password-Protected Directories feature adds a username-and-password challenge to a website directory. Creating the protected entry is only the first step: you must also add a user for that directory before an authorized visitor can open it.

This guide follows the Plesk Obsidian customer documentation. Labels and available controls can vary with the hosting plan and interface. The older screenshots have been retired because they show a legacy navigation layout, not a newly tested dashboard session.

Check the scope before you protect a folder

• Sign in to the Plesk account that manages the correct website or subscription. A directory-access user is not the same as a Plesk control-panel user.
• Confirm the domain’s document root and the folder you intend to restrict. A URL path routed through an application is not necessarily a separate filesystem directory.
• Use a working HTTPS address. A password challenge does not replace transport encryption.
• Keep account backups, database exports and credentials outside the public document root rather than treating a protected web folder as your backup-storage strategy.
• Identify any CDN, reverse proxy or existing cache in front of the website. Previously public copies need separate cache review; adding a password cannot recall a file someone already downloaded.

Create the protected directory entry

1. Open Websites & Domains for the intended domain.
2. Choose Password-Protected Directories, then Add Protected Directory.
3. Enter the directory path relative to this domain’s document root, such as /preview. Do not substitute an absolute server path or a complete URL.
4. Optionally set the protected-area title and save with OK.

Plesk for Linux can create the specified directory if it does not exist. Plesk for Windows requires an existing directory. Do not assume that adding protection creates or copies your website content.

Add at least one authorized user

1. Open the protected directory’s entry.
2. Choose Add a User.
3. Set a dedicated username and a strong, unique password, then save.

The user belongs to this protected directory, not automatically to every protected directory on the domain. Avoid sharing the main hosting-account password. To rotate access, open the user’s entry and change its password; to revoke that user’s access, remove the user from the directory.

Verify access with a harmless test file

Do not upload sensitive material merely to find out whether protection works. Place a harmless marker file in the intended folder, then check these cases:

1. Use a fresh browser session without saved credentials and request the directory’s HTTPS URL. It should require authentication rather than display the protected content.
2. Request the marker file directly, including its full filename. Test representative static files and subdirectories too, not only the directory’s index page.
3. Try an incorrect password and confirm that protected content is not returned.
4. Authenticate with the new directory user and confirm that the expected content loads.
5. Repeat through every public hostname or delivery path that can reach the content, including a CDN if one is configured.

Browsers may remember HTTP authentication credentials, so an already authenticated tab is not a reliable anonymous-access test. A normal unauthenticated challenge commonly returns HTTP 401; redirects, custom error pages and additional access controls can affect the response. The decisive check is that an unauthenticated request cannot retrieve the protected content.

Troubleshoot missing prompts or broken assets

If access fails for everyone, first confirm that a user was added to this specific directory and that the path matches the correct document root. If HTML is protected but a direct file URL is public, treat that as a failed protection test and stop placing private content there.

Static-file handling, custom nginx templates and cached responses can affect the result. Plesk documents a historical static-file issue in protected directories that was fixed in Obsidian 18.0.52. Check the installed version and actual server configuration with the administrator; do not blindly apply an old workaround or globally disable protections.

Remove protection deliberately

In Password-Protected Directories, select the directory and choose Remove Protection only when you intend its content to be publicly accessible through the remaining configuration. This removes the access restriction, not the website files. Removing every user is not the same as removing protection: with no authorized users, visitors still cannot authenticate.

Review scope: The creation, user-management and removal steps were checked against current primary documentation. No live Plesk account, customer credentials or protected production directory was modified or tested. If your interface or result differs, send InterServer support the domain, folder path, Plesk version and observed behavior, without sending passwords.

References: Plesk directory protection and users and Plesk’s static-file troubleshooting note.