DirectAdmin 1.695 Breaking Change: private_html to public_html Merge and What It Means for Your Sites

DirectAdmin 1.695, released on February 18, 2026, changes all web server configuration templates to use public_html as the document root for every virtual host. Before this release, HTTPS connections were served from private_html. If your server still has domains with a separate private_html directory instead of a symlink to public_html, those sites will break after the update. The fix is straightforward, but you need to act before the update hits your server or immediately after.

This article explains what changed, why it happened, which sites are affected, how to run the built-in maintenance task, and how to verify everything manually from SSH.

What DirectAdmin Actually Changed in 1.695

DirectAdmin ships a set of web server configuration templates that generate the actual Apache, Nginx, or OpenLiteSpeed virtual host files for every domain on the server. Before 1.695, the TLS-enabled templates pointed the document root at private_html. The non-TLS templates pointed at public_html. This meant HTTP and HTTPS could technically serve different content from different directories.

In practice, almost nobody used this feature. The web moved to HTTPS-everywhere years ago, and serving different content over HTTP versus HTTPS creates more problems than it solves. DirectAdmin recognized this back in version 1.649 (May 2023), when they deprecated the private_html directory toggle in the Evolution skin and started creating new domains with a private_html -> public_html symlink by default.

Version 1.695 finishes the job. The following template files now reference public_html instead of private_html:

• data/templates/nginx_server_secure.conf
• data/templates/nginx_server_secure_sub.conf
• data/templates/openlitespeed_vhost.conf
• data/templates/virtual_host2_secure.conf
• data/templates/virtual_host2_secure_sub.conf

After this update, when a visitor connects to your site over HTTPS, the web server looks in public_html. If you had a separate private_html directory with your actual site files in it (not a symlink), those files are now unreachable. The visitor gets a 403 Forbidden or sees an empty directory listing, depending on your configuration.

Who Is Affected

Most servers are not affected. Since DirectAdmin 1.52.0, new domains have been created with private_html as a symlink pointing to public_html by default. If your server was installed in the last five to six years and you never manually created separate private_html directories, you are fine.

You are at risk if any of the following apply:

• Your server was originally installed before DirectAdmin 1.52.0 and domains were never migrated to the symlink model
• You (or a previous admin) set default_private_html_link=0 in /usr/local/directadmin/conf/directadmin.conf at some point
• You migrated accounts from another server or another control panel, and the migration process created real private_html directories instead of symlinks
• A user manually deleted the symlink and created a directory through the Enhanced skin or SSH

In our experience managing DirectAdmin servers for web hosting clients, the most common scenario is old accounts that were migrated between servers years ago. The migration process preserved the original directory structure, and nobody noticed because the symlink versus directory distinction was invisible to the end user until now.

How to Check Your Server Before Updating

DirectAdmin provides a built-in maintenance task specifically for this situation. It was introduced in version 1.649 and is accessible at the Admin level in the Evolution skin.

Log in to DirectAdmin as an admin user. Navigate to Admin Tools > Maintenance Tasks. Look for the task named Ensure all domains private document roots link to public. Run it. The task scans every user account on the server and reports which domains still have a separate private_html directory instead of a symlink.

If the task reports zero affected domains, you can update to 1.695 without concern. If it reports affected domains, you need to resolve each one before the update.

Resolving Affected Domains

The resolution depends on whether the private_html and public_html directories contain the same files or different files.

Scenario 1: private_html Has the Site Files, public_html Is Empty or Outdated

This is the most common scenario on legacy accounts. The site was deployed into private_html because HTTPS was the primary access method, and public_html was either empty or contained stale files from the original setup. The fix is to move the files from private_html to public_html, remove the directory, and create the symlink.

From SSH as root or as the domain owner:

cd /home/USERNAME/domains/DOMAIN.COM

# Back up first
cp -a private_html private_html.bak

# Move files from private_html to public_html
rsync -av private_html/ public_html/

# Verify the files are in public_html
ls -la public_html/

# Remove the old directory
rm -rf private_html

# Create the symlink
ln -s public_html private_html

# Verify
ls -la private_html

The ls -la output should show private_html -> public_html. If it does, the domain will serve the same content over both HTTP and HTTPS after the update.

Scenario 2: Both Directories Contain Different Content

This is rare but possible. If someone deliberately served different content over HTTP and HTTPS, you need to decide which version to keep. In almost every case we have seen, the private_html version is the current one (since most traffic is HTTPS), and public_html is outdated.

Compare the directories:

diff -rq /home/USERNAME/domains/DOMAIN.COM/public_html \
         /home/USERNAME/domains/DOMAIN.COM/private_html

Review the differences. Back up both directories. Then follow the same rsync, remove, and symlink process from Scenario 1, using whichever directory contains the correct files as the source.

Scenario 3: Hundreds of Domains to Fix

If you manage a reseller server with many legacy accounts, fixing domains one by one is not practical. Here is a script that identifies all domains with a real private_html directory (not a symlink) and converts them. Run this as root. Read the script before executing it. Back up first.

#!/bin/bash
# Find all private_html directories that are NOT symlinks
find /home/*/domains/*/private_html -maxdepth 0 -type d 2>/dev/null | while read dir; do
    domain_dir=$(dirname "$dir")
    public_dir="$domain_dir/public_html"
    private_dir="$domain_dir/private_html"

    echo "Processing: $domain_dir"

    # Check if public_html exists
    if [ ! -d "$public_dir" ]; then
        echo "  WARNING: No public_html found, skipping"
        continue
    fi

    # Sync private_html content to public_html (preserving existing public_html files)
    rsync -a "$private_dir/" "$public_dir/"

    # Rename private_html as backup
    mv "$private_dir" "${private_dir}.bak.$(date +%Y%m%d)"

    # Create symlink
    ln -s public_html "$private_dir"

    echo "  DONE: Converted to symlink"
done

After running the script, re-run the DirectAdmin maintenance task to confirm zero affected domains remain. If you are a reseller hosting provider managing client accounts, coordinate with your clients before removing the .bak directories so they can verify their sites function correctly.

The Second Change You Should Not Ignore: Secure Access Group Migration

DirectAdmin 1.695 includes another change that gets less attention but can cause permission issues on older servers. The update automatically enables the secure_access_group option and forces the group name to access.

The secure access group makes web, email, and FTP services share the UNIX group access. This has been the default for new installations since DirectAdmin 1.33.3, released in April 2009. However, servers that predate this version, or servers where an administrator changed the group name to something other than access, will be affected.

If your server uses a custom secure access group name, the 1.695 update will rename it to access. This can break file permission setups that reference the old group name in ACLs, cron jobs, or custom scripts. Check your current configuration before updating:

grep secure_access_group /usr/local/directadmin/conf/directadmin.conf

If the output shows secure_access_group=access or the option is not present (meaning the default is already in effect), you have nothing to worry about. If it shows a different group name, audit your system for any references to that group before allowing the update to proceed.

OPcache API Access: A Quiet but Useful Fix

The 1.695 release also updates the default OPcache configuration file (custombuild/configure/opcache/opcache.ini) to stop blocking OPcache API access. In previous versions, the default config set opcache.restrict_api to a value that prevented PHP scripts from calling OPcache functions like opcache_reset() and opcache_get_status().

This matters if you use deployment tools or WordPress plugins that flush the OPcache after code changes. Before this fix, those tools would fail silently or throw errors depending on your PHP error reporting level. If you have been manually restarting PHP-FPM after deployments because OPcache was not clearing, this update may resolve that workflow issue. For a deeper understanding of how OPcache fits into your overall caching strategy, see our guide on full page cache vs object cache vs opcode cache.

Post-Update Verification Checklist

After updating to DirectAdmin 1.695, run through these checks to confirm nothing is broken:

1. Verify the symlinks are in place. Run this command as root to find any remaining real private_html directories:

find /home/*/domains/*/private_html -maxdepth 0 -type d 2>/dev/null | wc -l

The output should be 0. Any number greater than zero means you still have domains that need attention.

2. Test HTTPS on a sample of domains. Use curl to verify that HTTPS returns the expected content:

curl -sI https://yourdomain.com | head -20

Look for a 200 OK status code. A 403 Forbidden or 404 Not Found on a site that was working before the update likely points to a private_html directory that was not migrated.

3. Check the secure access group. Verify the group exists and that web-related processes are members:

getent group access

4. Rewrite the web server configuration. If you resolved any private_html issues after the update, force DirectAdmin to regenerate all virtual host configs:

echo "action=rewrite&value=httpd" >> /usr/local/directadmin/data/task.queue
echo "action=rewrite&value=nginx" >> /usr/local/directadmin/data/task.queue

Wait a few seconds for the task queue to process, then verify your sites again.

5. Check Let's Encrypt renewals. A previous 1.695 build had an issue where the .well-known HTTP challenge path failed when redirected to HTTPS. A subsequent build fixed this. Ensure your DirectAdmin is on the latest 1.695 build by running /usr/local/directadmin/directadmin v and checking the exact build date.

Why DirectAdmin Made This Change Now

The private_html directory dates back to a time when SSL certificates were expensive and most traffic was unencrypted. Serving different content over HTTP and HTTPS had a legitimate (if narrow) use case. That era ended years ago. Free certificates from Let's Encrypt, browser warnings on non-HTTPS pages, and search engine ranking factors all pushed the web to universal TLS.

DirectAdmin started the deprecation in version 1.649 (May 2023) by removing the private_html toggle from the Evolution skin. Version 1.650 made the symlink the default for all new domains regardless of the default_private_html_link setting in directadmin.conf. Version 1.695 completes the process by removing private_html references from the web server templates entirely.

The DirectAdmin team chose not to run a forced migration because merging directories with different content could cause data loss. Instead, they provide the maintenance task and leave the timing to server administrators. This is the right approach for a breaking change: document it clearly, provide tooling, and let the people who know the server make the call.

What ServerSpan Clients Need to Do

If you are on one of our web hosting plans, we have already handled this. Our shared hosting infrastructure runs DirectAdmin with the symlink model across all accounts. The 1.695 update did not break any sites because we migrated legacy accounts during a previous maintenance cycle.

If you run a VPS with DirectAdmin and manage it yourself, this article gives you everything you need to check and fix your setup. If you would rather not deal with it, our DirectAdmin management service covers exactly this kind of update review, pre-update audit, migration, and verification included.

For reseller accounts managing multiple clients, this is the kind of change that separates proactive providers from reactive ones. Run the maintenance task now, fix any affected domains, and communicate the change to your clients before they discover it through a broken site. If you need a hosting platform where these panel updates are handled for you, take a look at our reseller hosting packages.

After addressing the private_html merge, consider reviewing your overall site delivery pipeline. Pairing a properly configured DirectAdmin setup with Cloudflare can eliminate an entire class of performance issues. Our guide on how to optimize your free Cloudflare plan walks through the settings that matter most. And if you are weighing DirectAdmin against other panels for your next server, our DirectAdmin vs cPanel comparison breaks down the practical differences.