iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.
To enable WebDAV in Apache, load mod_dav and mod_dav_fs, create a writable lock database, map a repository, grant the Apache worker account filesystem access, and protect the location with authentication. Enable DAV only on the intended repository, then authorize write-capable methods separately from read and discovery requests. The configuration below uses Apache’s filesystem provider and is a template to adapt to your operating system, package layout, service account, and TLS setup.
What Apache WebDAV provides
WebDAV extends HTTP with methods that let a remote client work with server-side resources as files and collections. In addition to ordinary reads, a DAV client can create directories, upload files, move and copy resources, remove content, query properties, and use locking. That makes a DAV URL a write surface, not merely a browsable file listing. A mistake in authentication or filesystem permissions can therefore expose, alter, or delete the repository.
Apache’s mod_dav module implements the WebDAV methods and protocol handling. mod_dav_fs supplies the filesystem-backed provider. With the filesystem provider loaded, Dav On is an alias for the default filesystem provider. The provider stores resources in a directory that Apache can access and uses a separate lock database to coordinate WebDAV locks.
The example in this guide uses an Alias and a matching Directory container. A Location container or a different URL mapping can be appropriate in another virtual-host design, but the same requirements remain: a DAV provider, a writable lock database, repository permissions, and authentication on every DAV-enabled location.
#1 Best Overall
Decide the deployment shape first
Apache documentation establishes the filesystem-provider path but does not prescribe one universal topology. Make these choices before editing the configuration.
| Decision | Option | When it fits | Important consequence |
|---|---|---|---|
| DAV backend | Filesystem provider (mod_dav_fs) |
The repository should be ordinary files and directories on the Apache host. | Apache’s worker account must be able to read and write the tree, and out-of-band changes can conflict with DAV locking. |
| URL mapping | Alias plus Directory |
The public DAV path and filesystem path are different, such as /webdav mapped to /srv/webdav. |
The URL mapping and the filesystem authorization container must match exactly. |
| URL mapping | Location |
The policy is naturally expressed around a URL space or virtual host. | Keep the DAV directive and authentication policy scoped to the intended URL; do not enable it globally by accident. |
| Repository layout | One shared tree | A team uses common content and the same authorization policy. | Method and group rules apply to the whole tree unless you add more specific containers. |
| Repository layout | Separate trees | Users or projects need filesystem and authorization isolation. | Each mapping needs its own ownership, policy, and operational checks. |
| Authentication | Digest Authentication | You want Apache’s documented alternative to sending Basic credentials without transport protection. | The client must support Digest and the required Apache authentication modules and password-file format must be configured. |
| Authentication | Basic Authentication over TLS | Clients do not support Digest or your identity system terminates HTTPS in front of Apache. | Do not send Basic credentials over an unencrypted connection; enforce HTTPS for every request. |
Prerequisites and service-account facts
- Install or compile Apache with
mod_davandmod_dav_fs. Package names and module-loading syntax vary by operating system. - Know the Apache
UserandGroupconfigured for the worker processes. Common names differ between distributions, so use the values in your active Apache configuration rather than copying a name from another server. - Choose a repository directory, such as
/srv/webdav, and a separate directory for the lock database, such as/usr/local/apache2/var. - Have an authentication provider ready. A file-based Digest setup needs the corresponding authentication modules and a correctly formatted password file; a Basic setup needs TLS protection.
- Plan how clients will reach the endpoint over HTTPS and how certificates are managed. The DAV directives do not provide transport encryption by themselves.
Load and verify the DAV modules
Apache must load both layers of the filesystem implementation. Loading only mod_dav provides DAV protocol support but no filesystem provider; loading only mod_dav_fs is insufficient because it depends on the core DAV module. Enable the modules using the mechanism supplied by your package or build, then validate the effective configuration before restarting Apache.
Recommended Free Tools
Do not assume a module filename or configuration directory is identical across distributions. Some packages enable modules through separate include files, while a source build may use explicit LoadModule directives. Confirm that the running instance, not a different Apache installation on the host, is the one loading the modules.
Create the lock database safely
WebDAV locking requires a lock database. Define it with DavLockDB at server or virtual-host scope:
DavLockDB "/usr/local/apache2/var/DavLock"The value is a base path; do not append the database’s generated extension. Apache creates and uses the related files in the containing directory. That directory must already exist and be writable by the configured Apache User and Group. Apache recommends a dedicated directory for the lock database rather than placing it inside the content tree.
Rank #2
- Used Book in Good Condition
Keep the lock directory outside the repository and outside any URL that Apache serves. This prevents clients from downloading lock files and avoids accidental deletion when content is synchronized or replaced. Set ownership and permissions for the Apache service account while denying unrelated users write access. The exact chown, group, and mode commands depend on your operating system; the invariant is that the worker account can create, update, and remove the lock files.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minuteInclude the lock directory in your operational plan. A lock database is runtime state rather than user content, so back it up only if your recovery procedure requires it and never restore it with ownership that prevents Apache from opening it. If you move it, update DavLockDB and preserve the containing-directory permissions before restarting Apache.
Prepare repository ownership and permissions
Create the repository at the filesystem path you intend to expose, then grant the Apache worker account the access it needs. The account must be able to traverse parent directories, read existing content, create and modify files, create directories, and remove or rename resources when your policy permits those methods.
Apache warns that files created through DAV are owned by its configured User and Group. Design group membership and default permissions around that fact. Do not let an unrelated FTP account, deployment job, or shell user routinely modify the same tree behind Apache’s back: those changes bypass DAV locking and can produce stale locks, surprising ownership, or content that clients cannot update.
- Verify every parent directory from the filesystem root to the repository is searchable by the Apache account.
- Give the service account write access only to the intended repository, not to a broad parent such as an entire home directory.
- Check that existing files and directories have compatible read, write, and execute permissions.
- If another process must publish files, coordinate ownership and group permissions explicitly and understand that it is outside WebDAV’s lock coordination.
- Keep the lock database directory’s permissions separate from repository permissions.
Map the URL and enable DAV only there
The following shape maps /webdav to /srv/webdav. It is illustrative rather than a tested, drop-in deployment: module-loading syntax, authentication directives, TLS settings, password-file paths, and the Apache service account vary by platform.
Rank #3
DavLockDB "/usr/local/apache2/var/DavLock"
Alias "/webdav" "/srv/webdav"
<Directory "/srv/webdav">
Dav On
AuthType Digest
AuthName "WebDAV"
AuthDigestProvider file
AuthUserFile "/etc/apache2/webdav.passwd"
Require valid-user
<LimitExcept GET OPTIONS>
Require group dav-admin
</LimitExcept>
</Directory>Dav On belongs in the repository’s authorization container, not in a global default that could expose unrelated directories. If you use a Location container instead, make sure the URL policy and filesystem mapping still point to the intended tree. Test for overlapping Directory, Location, and virtual-host rules; a broader container can override or weaken the policy you thought applied.
The authorization example requires an authenticated user for all methods and then requires membership in dav-admin for methods other than GET and OPTIONS. Adapt the group and method set to your client and risk model. Some deployments also permit POST to a less-privileged policy, as in Apache’s documented method-authorization example, but POST is not a universal read-only operation. Treat it according to what your application actually does.
Protect every DAV location with authentication
Apache’s guidance is explicit: any location where DAV is enabled should be protected by authentication. Do not publish an unauthenticated DAV share merely because the directory is intended for internal users. A client that can reach the endpoint may otherwise create, move, copy, or delete resources.
Digest Authentication
Digest Authentication is the documented alternative when you do not want to send Basic credentials without transport protection. Configure the Digest authentication modules, a realm name, and the password-file directive required by your Apache build. The client must support Digest, and the realm used to generate the credentials must remain consistent with the server configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Basic Authentication over TLS
Basic Authentication can be used when the entire connection is protected by SSL/TLS. Enforce HTTPS at Apache or at a trusted TLS-terminating proxy, redirect or reject clear-text requests, and ensure the proxy forwards the authenticated request only over a protected internal path. Basic credentials sent over plain HTTP are not an acceptable substitute for TLS.
Authenticate before narrowing methods
Method-level authorization should refine an already authenticated policy. A rule that grants GET or OPTIONS through a broad Require method provider can unintentionally permit anonymous discovery or reads. If your goal is authenticated read access with restricted writes, keep Require valid-user (or an equivalent identity requirement) on the DAV container and add a group or role requirement for write-capable methods.
Authorize DAV methods deliberately
WebDAV has more write-capable methods than an ordinary browser uses. At minimum, review PUT, DELETE, MKCOL, MOVE, COPY, PROPPATCH, LOCK, and UNLOCK. Discovery and read operations commonly include GET, HEAD, OPTIONS, and PROPFIND, although a PROPFIND request can reveal directory structure and metadata.
Do not assume that a client needs every method. Start with the smallest set that supports the workflow, then add methods when a known client operation fails. Separate groups for read-only users and editors if the repository contains sensitive or destructive content. Keep administrative methods such as lock management restricted to the users who need them unless your client demonstrably requires a broader policy.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Apache’s documented pattern distinguishes GET, POST, and OPTIONS from other methods, requiring an authenticated administrator for the latter. That is a pattern to adapt, not a universal safe list. In a secure baseline, authenticate all requests and make the write-method rule explicit, as shown in the configuration above.
Control DAV XML request size
DAV clients send XML bodies for operations such as property and lock requests. If you need a request-size limit for those bodies, use Apache’s LimitXMLRequestBody directive in the applicable server, virtual-host, or directory scope. The ordinary LimitRequestBody directive has no effect on DAV requests, so setting only that directive does not provide the control you expect.
Best Value
Choose a limit that accommodates the largest legitimate property or lock request generated by your clients, then test the failure response with a representative request. A limit that is too low can break directory synchronization even though ordinary file uploads continue to work.
Validate the configuration before opening access
- Confirm that the active Apache instance loads
mod_davandmod_dav_fs, and that the authentication modules required by your chosen scheme are present. - Create the lock directory and repository, assign ownership to the configured Apache
UserandGroup, and verify that the worker account can write both locations. - Run Apache’s configuration check using the command supplied by your installation, then fix every syntax error before reloading.
- Reload or restart Apache using the service manager for that installation. Watch the error log during startup for lock-database, permission, or module errors.
- From an authenticated client, issue an
OPTIONSrequest to the DAV URL and confirm that the response identifies the expected DAV capability. - Issue an authenticated
PROPFINDrequest against a test collection. Verify that directory discovery works only for users who should have it. - Test a small upload, directory creation, move, copy, lock, unlock, and deletion with the intended editor account. Repeat the tests with a read-only account and confirm that write methods are rejected.
- Inspect the resulting files. Confirm their owner, group, mode, and location, and ensure no test content escaped the repository.
- Test an unauthenticated request and a clear-text HTTP request. Both should be rejected or redirected according to your security policy, without exposing the repository.
A simple command-line sequence can help isolate protocol and authorization problems, but substitute your real HTTPS hostname and credentials and do not place passwords in shell history:
curl -i -X OPTIONS https://dav.example.test/webdav
curl -i -u user:password -X PROPFIND -H 'Depth: 1' https://dav.example.test/webdav/
curl -i -u user:password -T ./test.txt https://dav.example.test/webdav/test.txt
curl -i -u user:password -X DELETE https://dav.example.test/webdav/test.txtUse a disposable test file and remove it after validation. A successful GET proves only that reads work; it does not prove that the lock database, repository writes, or method authorization are correct.
Troubleshoot the common failure modes
| Symptom | Likely cause | Checks and corrective action |
|---|---|---|
| Apache fails to start after adding DAV | A module, directive, path, or authentication setting is unavailable or misspelled. | Run the installation’s configuration test, verify that both DAV modules are loaded, and confirm that every referenced directory and password file exists. |
| Requests return a lock-database error or HTTP 500 | The DavLockDB parent directory is missing, not writable, or inaccessible to the worker account. |
Create the dedicated parent directory, correct ownership and permissions, keep the path free of a database extension, and inspect the error log while retrying. |
| Files can be read but uploads fail | The repository is readable but not writable by Apache, or write methods are denied by authorization rules. | Check directory traversal and write permissions for the Apache account, then review PUT, MKCOL, and other method restrictions. |
| Upload succeeds but a later edit fails | New files are owned by Apache or have modes that prevent the editing account or cooperating process from changing them. | Inspect ownership and group permissions. Align the repository policy with Apache-created files instead of changing files behind DAV with an unrelated tool. |
| Clients repeatedly ask for credentials | The client does not support the selected authentication scheme, the realm or password file is wrong, or a proxy is stripping authentication headers. | Test with a known-compatible client, verify the authentication module and file, and inspect the proxy and TLS path. |
| Unauthenticated reads succeed | A Require method rule grants a method without an identity requirement, often through a broad RequireAny block. |
Require an authenticated user on the DAV container, then apply group restrictions to write methods. Re-test with no credentials. |
| The DAV URL returns 404 or exposes the wrong directory | The Alias, Directory, virtual host, or URL path does not match the request. |
Check the active virtual host and normalized trailing slash, confirm the filesystem path, and look for overlapping mappings. |
| Locks appear stale or clients report conflicting edits | The lock database was moved, deleted, restored with incorrect ownership, or the repository was changed outside DAV. | Restore the configured lock path and permissions, review how the lock state was handled during recovery, and stop unmanaged processes from modifying the tree. |
| Large metadata operations are rejected while file uploads work | LimitXMLRequestBody is too low for the client’s DAV XML request. |
Increase the XML-specific limit to a justified value and remember that LimitRequestBody does not control DAV XML requests. |
Operational safeguards after deployment
Keep the endpoint narrowly scoped
Use a dedicated repository and enable Dav On only in its container. Do not turn on DAV in a document root that also contains application code, configuration files, logs, or user-uploaded data with a different trust model.
Monitor destructive activity
Review Apache access and error logs for unexpected DELETE, MOVE, COPY, LOCK, and UNLOCK requests. Alert on repeated authentication failures and unusual method patterns. Logging cannot undo a deletion, so pair it with filesystem backups and a tested restore procedure.
Coordinate backups and locks
Back up repository content with ownership and permissions preserved. Decide whether the lock database is rebuilt or restored during recovery, document that decision, and make sure the restored path is writable by Apache before clients reconnect.
Review client behavior
Different DAV clients use different method sequences and may require directory discovery, locks, or property updates even for an apparently simple save operation. Capture the failing method from the access log before broadening permissions. Grant only the additional method or group membership that the workflow requires.
Configuration checklist
- Modules:
mod_davandmod_dav_fsare loaded by the active Apache instance. - Lock database:
DavLockDBpoints to a base path outside the content tree, with a dedicated writable parent directory. - Repository: The URL mapping resolves to the intended filesystem path, and
Dav Onis limited to that path. - Permissions: Apache can traverse, read, create, modify, move, and remove resources required by the selected method policy.
- Authentication: Every DAV-enabled location requires an authenticated identity; Digest is used, or Basic is used only over TLS.
- Authorization: Read, discovery, and write methods are reviewed separately, with destructive methods restricted to intended users.
- Request limits: Any DAV XML-size requirement uses
LimitXMLRequestBody, not justLimitRequestBody. - Testing: Authenticated and unauthenticated requests, read-only and editor accounts, lock operations, ownership, logs, and recovery procedures have all been verified.
What a secure final design looks like
A sound Apache WebDAV deployment has a narrow URL mapping, a filesystem provider enabled only for that repository, a lock database in its own Apache-writable directory, and filesystem ownership that matches the worker account. Authentication covers the entire DAV location, while method-level rules give ordinary users only the operations they need and reserve destructive or administrative methods for an authorized group. Once those controls are in place, test the actual client workflow rather than assuming that a successful read means the endpoint is ready for writes.
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.
