When Apache stops with AH00015: Unable to open logs or (13) Permission denied, repair the log path and its permissions before changing application code. Apache opens its configured logs during startup, so a missing directory, an inaccessible parent, a bad symlink, an incorrect owner, or a SELinux/AppArmor denial can terminate the daemon before a normal error log is written.
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
Find the effective ErrorLog and CustomLog destinations, inspect every directory in each path, restore the package’s intended ownership and least-privilege modes, test the configuration, then perform a real service restart and confirm that a fresh log entry is created.
As an Amazon Associate I earn from qualifying purchases.
What “unable to open logs” means
Apache httpd normally starts a privileged parent process and later runs worker processes with reduced privileges. Log files are opened as part of initialization, before those workers serve requests. If the parent cannot traverse a directory, open or create a configured file, or follow a symlink to an accessible target, startup can abort. Because logging itself failed, the daemon may exit without writing the diagnostic you expected.
The most recognizable message is AH00015: Unable to open logs. The same incident may include (13) Permission denied, “unable to open logs,” or a path-specific error. A syntax check can succeed while startup still fails, because syntax validation does not prove that the service account can access every log destination at runtime.
The ErrorLog directive selects the error-log destination. A relative ErrorLog path is resolved relative to Apache’s ServerRoot, not relative to your shell’s current directory. Virtual-host files and included configuration fragments can define additional ErrorLog and CustomLog paths. Repairing a familiar default such as /var/log/httpd or /var/log/apache2 is ineffective if the active configuration points somewhere else.
Start with the exact failure output
Do not begin by recursively changing permissions. First preserve the message and the path that Apache actually reported. The service manager often has the only copy when no error log was opened.
Recommended Free Tools
- Check the service status using the unit name installed by your distribution, commonly
apache2orhttpd:systemctl status apache2systemctl status httpd - Read the unit’s recent journal entries. Substitute the unit that exists on your host:
journalctl -u apache2 -bjournalctl -u httpd -b - Copy the complete startup attempt, including the timestamp,
AH00015, the operating-system error number, and any path. A message naming a directory is more useful than a generic “failed” status. - Record whether the failure occurs on boot, on every manual restart, or only after log rotation. That timing helps distinguish a static permission problem from a rotation or policy change.
Apache’s documentation states that a fatal startup problem is written to the console or to ErrorLog before exit. When log access is the fatal problem, the console or journal is therefore the authoritative first location.
Locate the effective log destinations
Inspect the configuration that the service actually uses, including files pulled in by Include or IncludeOptional. Look for global and virtual-host definitions of both directives:
ErrorLog /path/to/error_log
CustomLog /path/to/access_log combinedResolve relative paths against the active ServerRoot. Do not infer the path from a distribution’s usual layout. A virtual host can send logs to a directory entirely different from the global server log, and one inaccessible virtual-host path is enough to prevent the overall configuration from starting.
Use the Apache binary and configuration selected by your distribution when testing. Debian-family systems commonly provide apachectl; other packages provide httpd. If more than one installation exists, make sure the command examines the same configuration and binary that the service unit launches. Otherwise you can repair one tree while the service reads another.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Inspect every component of the path
File permissions alone do not explain all access failures. The process must have search (x) permission on every parent directory, read or write permission appropriate to the log operation, and permission to traverse any symlink target. Inspect the complete path rather than only the final filename.
- Run
namei -l /path/to/error_log. This displays each component, its owner, group, and mode, making a missing search bit on an otherwise ordinary parent visible. - Run
stat /path/to/error_log. Confirm whether the final object exists, whether it is a regular file or symlink, and which owner, group, and mode it has. - Run
ls -ldon the log directory and every parent directory. For example:ls -ld / /path /path/to /path/to/logs - If the log is a symlink, inspect the target path with the same commands. The target’s directories and file permissions must be usable by the process that opens the log; fixing only the link itself does not help.
- Check that the configured directory exists. A typo, a removed mount point, or a log directory deleted during cleanup produces the same startup symptom as a permission denial.
“Permission denied” can therefore mean “cannot search this parent,” not merely “the file is not writable.” A directory mode that removes search permission for the relevant user or group blocks access even when the final file appears permissive.
Confirm which account needs access
Apache package layouts differ. The startup parent may begin as root and later drop privileges; worker processes may run as a distribution-specific service user. Determine the account and groups defined by the active service configuration rather than guessing from a tutorial. Also identify the owner and group intended for the log directory and files.
Restore the package’s intended ownership and least-privilege modes. A typical repair has these characteristics, but the exact user, group, and numeric modes must come from your distribution’s defaults and local policy:
- The directory is owned by an administrative account or the package’s designated log owner.
- The process that must create or append logs has the required directory search and write permissions.
- Unrelated users do not receive write access.
- Existing log files retain the group and mode expected by readers, monitoring tools, and rotation jobs.
If a directory or file is missing, create it with those intended settings instead of creating a world-writable substitute. An administrator can use an explicit command after replacing placeholders with verified local values, for example:
install -d -o <owner> -g <group> -m <directory-mode> /path/to/logs
install -o <owner> -g <group> -m <file-mode> /path/to/logs/error_logOnly create the file when the active configuration expects Apache to open a regular file at that exact path. If the path is a symlink, repair or recreate the target according to the package’s layout instead.
Never apply chmod -R 777 to a log tree. It may make the immediate error disappear while granting every local user the ability to alter files that a privileged process opens.
Why a writable log directory is a security risk
Apache warns that anyone who can write to the directory where httpd writes a log can potentially obtain the UID under which the server starts, normally root. A malicious user may replace a log, manipulate a symlink, or influence a file that the privileged startup process opens. The repair must therefore preserve ownership and restrict directory write access, not simply maximize permissions until startup succeeds.
Separate “must open the log” from “should read the log.” The service may need directory write permission to create or rotate a file, while operators, a monitoring group, or a log collector need read access. Grant those capabilities through the intended owner and group, and keep other users out. Review the complete path for writable parent directories as well as the final log directory.
Check SELinux, AppArmor, and other mandatory policy
If Unix owner, group, and mode bits are correct but Apache still reports access denied, check mandatory-access-control policy. SELinux labels or an AppArmor profile can deny an operation that ordinary permission commands show as allowed. Examine the host’s audit and journal records at the time of the failed start; look for a denial naming Apache, the log path, or the target of a symlink.
Use the remediation procedure documented for the policy and distribution in question. That may involve restoring a package-approved label, adjusting a profile rule, or moving logs to a policy-approved location. Do not disable SELinux or AppArmor globally as a troubleshooting shortcut. A policy change should be narrow, recorded, and tested with a subsequent restart.
When a mount, container, or network filesystem is involved, include its policy and mount options in this branch. A path can be visible in your interactive shell yet inaccessible to the service’s namespace or confined profile.
Free tools Windows power users keep installed
One-click scans. No signup required.
Validate configuration before restarting
After correcting the path, directory, file, or policy, run the distribution’s configuration test with the same configuration used by the service:
apachectl -thttpd -t
A successful result confirms that Apache can parse the configuration. It does not replace a real start, because the service manager, environment, privileges, mounts, and policy can differ from an interactive test.
If the test reports another error, fix that error first. Pay particular attention to a typo in an included virtual-host file or a relative path resolved from an unexpected ServerRoot. Repeat the test after each material change so that the final successful result corresponds to the files you intend to run.
Perform and verify a real service start
- Start or restart through the service manager, not only by launching a foreground process:
systemctl restart apache2systemctl restart httpd - Immediately check that the unit is active and that no new permission denial appears in its journal.
- Inspect the configured error log and confirm that it has a fresh entry from this start. If the file remains unchanged, verify that you are reading the effective path, not a similarly named default file.
- Generate a harmless local request if necessary, then confirm that the configured access log receives the expected entry. This checks the
CustomLogdestination as well as the error log. - Repeat the check after a normal stop and start, and after a reboot if the original failure occurred during boot. A fix that works only in the current shell or before a mount is available is not durable.
Leave the journal output and the successful configuration-test result with the change record. They provide a baseline if the same path fails again after a package update or rotation event.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Match the symptom to the repair
| Observed condition | What to inspect | Appropriate repair | Durability check |
|---|---|---|---|
AH00015 names a path that does not exist |
Each parent with namei -l and ls -ld |
Create the intended directory or correct the configuration path, then apply package-approved owner, group, and mode | Restart through the service manager and confirm a fresh log entry |
| Final file exists but access is denied | stat output, file owner/group/mode, and the account Apache starts with |
Restore only the required ownership and write or append permission | Test both error and access-log writes |
| One parent directory lacks search permission | Every path component, not only the log file | Add the narrowly required search permission or change the directory layout according to local policy | Repeat the test after a fresh login or reboot |
| The configured path is a symlink | Link target and all target directories | Make the target accessible under the intended policy, or remove the link in favor of the package layout | Restart and verify the target receives the new entry |
| Mode bits look correct but the journal records a policy denial | SELinux/AppArmor audit and journal records | Apply the distribution’s documented label or profile correction; do not disable mandatory controls | Confirm the denial disappears on two consecutive starts |
| Starts successfully until log rotation | Rotation-created file, replacement directory, owner/group, mode, and post-rotate command | Make the rotation configuration recreate logs with the same intended access and policy attributes | Run or wait for one rotation cycle, then restart and check both logs |
Common fixes that fail, and why
Changing only the final file mode
The parent directory may still lack search permission, or a symlink target may remain inaccessible. Inspect the entire path before and after the change.
Repairing the default log directory
The active ErrorLog may be relative to ServerRoot or defined inside an included virtual-host file. Confirm the effective configuration first.
Running a syntax test and stopping there
apachectl -t or httpd -t validates parsing. Only a service-manager start proves that the runtime account, mounts, and mandatory policy can open the logs.
Making the directory world-writable
This trades a startup symptom for a privilege-escalation exposure. Preserve least privilege and investigate the intended package ownership instead.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Fixing the current file while rotation recreates a bad one
Log rotation can delete and recreate files with a different owner, group, mode, label, or directory. Inspect the rotation configuration and test a complete cycle.
Assuming no new error log means no error
When Apache cannot open its error log, the absence of a new file entry is expected. Use the console and service journal for the initial diagnosis.
A repeatable checklist
- Capture the complete service-manager or console message, including the named path and
AH00015orPermission denied. - Identify the active binary,
ServerRoot, global configuration, included files, and all effectiveErrorLog/CustomLogdestinations. - Resolve relative paths and inspect each parent with
namei -l,stat, andls -ld. - Confirm the startup account, intended owner and group, and least-privilege directory and file modes.
- Check symlink targets, missing directories, mounts, and rotation-created replacements.
- Review SELinux/AppArmor audit or journal denials when Unix permissions appear correct.
- Run
apachectl -torhttpd -tusing the service’s configuration. - Restart through the service manager and verify an active unit, a fresh error-log entry, an access-log entry, and a clean journal.
This sequence fixes the cause rather than masking it: the path is correct, every directory is traversable, the intended account has only the permissions it needs, mandatory policy permits the operation, and the result survives a real restart and future log rotation.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
