Иногда задача звучит просто: положить файл на сервер, чтобы его можно было открыть с другого компьютера. Есть VPS, есть Nginx, есть HTTPS, есть Windows, которая умеет подключать сетевые диски. На бумаге всё красиво: сейчас быстро сделаем облачную папку и разойдёмся пить чай.
Потом в кадр заходят WebDAV, служба WebClient, Basic Auth, реестр Windows, Access-файлы, lock-файлы, сетевые диски, которые вроде диски, но не совсем те диски. И становится понятно: слово «сетевой диск» в Windows может означать разные технологии.
В этой статье разберём, что такое WebDAV, чем он отличается от обычной Windows-сети SMB, как настроить WebDAV на Nginx и как подключить HTTPS-папку в Windows как диск Z:.
Сразу важное предупреждение: WebDAV может быть полезен для обмена файлами и технических задач, но это не замена нормальной серверной базе данных. И уж точно не волшебный способ превратить Microsoft Access в надёжное веб-приложение. Было бы удобно, но жизнь не настолько щедра.
Что такое WebDAV
WebDAV расшифровывается как Web Distributed Authoring and Versioning. Если по-человечески, это расширение HTTP, которое позволяет не только скачивать файлы с веб-сервера, но и управлять ими: загружать, удалять, создавать папки, перемещать и получать список файлов.
Обычный сайт чаще всего работает так:
GET /file.pdf
Клиент просит файл, сервер отдаёт файл. Всё спокойно.
WebDAV добавляет к этому методы для работы с файлами:
PUT загрузить или перезаписать файл DELETE удалить файл MKCOL создать папку COPY скопировать файл MOVE переместить файл PROPFIND получить список файлов и свойства OPTIONS узнать, что сервер умеет
На практике это позволяет сделать URL вида:
https://example.com/db/
А потом подключить эту папку в Windows как сетевой диск. Пользователь видит букву диска, а обмен файлами идёт через HTTPS.
WebDAV это не SMB
Вот здесь чаще всего начинается путаница.
Когда человек говорит «сетевой диск Windows», он часто имеет в виду обычную сетевую папку:
\\server\share
Это SMB/CIFS, Windows File Sharing. Такой сценарий обычно живёт внутри локальной сети: офис, сервер, рабочие компьютеры, общий ресурс.
Пример SMB-диска:
Z: = \\office-server\documents
WebDAV выглядит иначе:
Z: = https://example.com/db/
В Проводнике Windows оба варианта могут выглядеть как диск Z:, но внутри это разные протоколы.
- SMB это файловая шара Windows.
- WebDAV это HTTP/HTTPS-доступ к файлам через службу WebClient.
Поэтому фраза «у меня появился сетевой диск» ещё не говорит, какой протокол используется. Windows умеет спрятать под одной буквой диска разные механизмы. Удобно? Иногда. Понятно? Ну, Microsoft старалась как могла.
Можно ли открыть SMB через интернет
Технически можно открыть наружу порт 445/tcp.
Практически так делать не надо.
SMB наружу в интернет это плохая идея по безопасности. Многие провайдеры режут этот порт, а даже если не режут, выставлять Windows-шару в публичную сеть без VPN это приглашение на неприятности.
Нормальная схема для SMB через интернет выглядит так:
VPN → внутренняя сеть → \\server\share
Пользователь сначала подключается к VPN, попадает как будто в офисную сеть, и уже потом открывает обычную SMB-папку.
Если VPN нет, а нужен доступ к отдельной папке через HTTPS, тогда можно смотреть в сторону WebDAV.
Когда WebDAV уместен
WebDAV можно использовать, когда нужно быстро организовать файловый доступ через HTTPS без полноценного файлового сервера.
Нормальные сценарии:
- получить удалённую папку через HTTPS;
- загружать и скачивать файлы без отдельного FTP/SFTP-клиента;
- подключить папку в Windows как сетевой диск;
- дать доступ к отдельному каталогу по логину и паролю;
- быстро организовать файловый обмен на VPS;
- дать пользователю путь вида Z:\file.ext вместо объяснений про SSH и SCP.
Но WebDAV не стоит воспринимать как универсальную замену всему.
- Он не заменяет SFTP для администрирования сервера.
- Он не заменяет SMB внутри локальной сети.
- Он не заменяет полноценную веб-систему.
- Он не превращает Access-файл в нормальную облачную базу данных.
WebDAV хорош, когда вы понимаете его границы. Если попытаться сделать из него всё сразу, он быстро превращается в квест с Windows, паролями и странными ошибками.
Задача
Допустим, есть сайт:
example.com
Нужно сделать защищённую папку:
https://example.com/db/
В этой папке будет лежать файл:
newbd.accdb
Windows должна подключать эту папку как диск:
Z:
А пользователь должен видеть путь:
Z:\newbd.accdb
Домены, логины и пути в статье примерные. В реальном проекте подставляйте свои значения и не публикуйте рабочие пароли. Да, звучит очевидно, но интернет полон людей, которые однажды подумали: «да кто это увидит».
Установка модулей на Debian и Ubuntu
Для Basic Auth нужен пакет apache2-utils, потому что в нём есть утилита htpasswd.
Для расширенного WebDAV в Nginx на Debian и Ubuntu обычно нужен модуль libnginx-mod-http-dav-ext.
sudo apt update sudo apt install -y apache2-utils libnginx-mod-http-dav-ext
Проверим Nginx:
sudo nginx -t
Если конфигурация валидна, Nginx ответит примерно так:
syntax is ok test is successful
Если есть ошибка, сначала исправляем её, а уже потом идём дальше. Nginx не вредничает. Он просто не хочет падать вместе с вашим вечером.
Создаём папку для WebDAV
Создадим отдельный каталог вне корня сайта. Это важный момент: не надо давать WebDAV-доступ прямо в каталог WordPress. Сайт отдельно, файлы WebDAV отдельно.
sudo mkdir -p /srv/example-db sudo chown -R www-data:www-data /srv/example-db sudo chmod 750 /srv/example-db
Если нужно положить тестовый файл:
echo "test" | sudo tee /srv/example-db/test.txt sudo chown www-data:www-data /srv/example-db/test.txt
Права можно настраивать строже под конкретную задачу, но для базового WebDAV через Nginx важно, чтобы пользователь, от которого работает Nginx, мог читать и записывать файлы в этот каталог.
Создаём пользователя и пароль
Создадим файл паролей для Basic Auth:
sudo htpasswd -c /etc/nginx/.htpasswd-example-db dbuser
Ключ -c используется только при создании нового файла. Для добавления второго пользователя его уже не указываем:
sudo htpasswd /etc/nginx/.htpasswd-example-db seconduser
Права на файл паролей:
sudo chown root:www-data /etc/nginx/.htpasswd-example-db sudo chmod 640 /etc/nginx/.htpasswd-example-db
Basic Auth используем только поверх HTTPS. Без HTTPS пароль будет передаваться небезопасно. Это не «ну ладно, тестовый сервер», это прямой путь к неприятному разговору с самим собой.
Конфигурация Nginx
Ниже пример location для WebDAV. Его нужно добавить в server-блок нужного сайта.
location = /db { return 301 https://$host/db/; } location ^~ /db/ { alias /srv/example-db/; auth_basic "Protected WebDAV"; auth_basic_user_file /etc/nginx/.htpasswd-example-db; client_max_body_size 512M; dav_methods PUT DELETE MKCOL COPY MOVE; dav_ext_methods PROPFIND OPTIONS; create_full_put_path on; dav_access user:rw group:rw all:r; autoindex on; autoindex_exact_size off; autoindex_localtime on; types { application/octet-stream accdb mdb laccdb; } default_type application/octet-stream; add_header DAV "1,2" always; add_header MS-Author-Via "DAV" always; add_header X-Robots-Tag "noindex, nofollow, noarchive" always; add_header Cache-Control "private, no-store, no-cache, must-revalidate" always; }
Важный момент:
location ^~ /db/ { alias /srv/example-db/; }
И location, и alias заканчиваются слешем. Это нужно, чтобы Nginx корректно сопоставлял URL и файловый путь. Если со слешами ошибиться, можно получить странное поведение, 404 или доступ не туда, куда планировали.
Проверяем конфигурацию и перезагружаем Nginx:
sudo nginx -t sudo systemctl reload nginx
Проверка WebDAV через curl
Сначала проверим список файлов через PROPFIND:
curl -u dbuser -X PROPFIND https://example.com/db/ -H "Depth: 1"
Если всё хорошо, в ответе будут XML-данные со списком ресурсов.
Проверим загрузку файла:
echo "hello webdav" > /tmp/dav-test.txt curl -u dbuser -T /tmp/dav-test.txt https://example.com/db/dav-test.txt
Проверим чтение:
curl -u dbuser https://example.com/db/dav-test.txt
Проверим удаление:
curl -u dbuser -X DELETE https://example.com/db/dav-test.txt
Если загрузка, чтение и удаление работают, серверная часть WebDAV настроена. Дальше начинается отдельный праздник под названием Windows WebClient.
Подключение WebDAV в Windows
В Windows за WebDAV отвечает служба WebClient. Без неё подключение через net use может не заработать.
Откройте командную строку от имени администратора и включите службу:
sc config WebClient start= auto net start WebClient
Если Windows пишет, что служба уже запущена, это нормально.
Теперь лучше закрыть административную командную строку и открыть обычную командную строку, уже не от имени администратора. Это важно для видимости диска в обычном Проводнике пользователя.
Подключаем диск:
net use Z: "https://example.com/db/" /user:dbuser * /persistent:yes
Windows попросит пароль. После успешного подключения в «Этот компьютер» появится диск Z:.
Проверить можно так:
dir Z:\
Или открыть в Проводнике:
explorer Z:\
Почему диск лучше подключать не из админской CMD
В Windows есть неприятный нюанс: диск, подключённый из командной строки администратора, может не отображаться в обычном Проводнике пользователя.
Поэтому для обычной работы лучше подключать диск из обычной CMD:
net use Z: "https://example.com/db/" /user:dbuser * /persistent:yes
Если диск уже занят:
net use Z: /delete /y
И затем подключить снова:
net use Z: "https://example.com/db/" /user:dbuser * /persistent:yes
Это один из тех моментов, где Windows не сломана, она просто живёт в своей административной реальности. Пользовательская сессия отдельно, повышенная сессия отдельно, нервы общие.
Если Windows не подключает WebDAV
Иногда Windows выдаёт ошибки вроде:
Системная ошибка 67 Не найдено сетевое имя
Или постоянно просит пароль.
Первое, что нужно проверить:
sc query WebClient
Служба должна быть запущена.
Если используется Basic Auth через HTTPS, иногда требуется включить соответствующий режим WebClient:
reg add HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters /v BasicAuthLevel /t REG_DWORD /d 2 /f net stop WebClient net start WebClient
После этого снова пробуем подключить диск:
net use Z: "https://example.com/db/" /user:dbuser * /persistent:yes
Ещё раз: Basic Auth без HTTPS использовать не стоит. Если парольная авторизация идёт по открытому HTTP, это не настройка, а заявка на будущую проблему.
WebDAV и Microsoft Access
Теперь самый скользкий момент.
Файл Access .accdb можно положить в WebDAV-папку. Windows может подключить эту папку как диск Z:. Access может открыть файл по пути:
Z:\newbd.accdb
Но это не значит, что мы получили полноценную облачную базу данных.
Access в формате .accdb это файловая база. Программа Microsoft Access открывает файл напрямую. При работе рядом может появляться lock-файл:
newbd.laccdb
Это нормально для Access. Но при работе через интернет и WebDAV всё зависит от конкретной Windows, службы WebClient, версии Access, политик безопасности и качества соединения.
Для одного пользователя такой вариант можно рассматривать как экспериментальный. Особенно если файл раньше просто лежал на флешке или локальном диске, а теперь нужно попробовать открыть его удалённо.
Для серьёзной работы это не лучшее решение.
Если нужна нормальная работа «из любой точки», правильнее делать отдельную систему:
- серверную базу данных;
- веб-интерфейс;
- авторизацию;
- роли доступа;
- резервные копии;
- импорт данных из Access;
- отдельные формы и отчёты.
То есть это уже не «положить файл на VPS», а отдельный проект по переносу Access-логики в веб. Скучнее, дороже, зато надёжнее.
Чем WebDAV отличается от нормальной веб-базы
WebDAV-сценарий выглядит так:
Пользователь → Windows WebClient → HTTPS/WebDAV → файл .accdb на сервере
Нормальная веб-система выглядит иначе:
Пользователь → браузер → веб-приложение → серверная БД
Во втором случае пользователь не открывает файл базы напрямую. Он работает через интерфейс. Это надёжнее, безопаснее и понятнее для удалённой работы.
WebDAV может решить задачу доступа к файлу. Но он не решает архитектурную задачу приложения. Это как прикрутить багажник к самокату: иногда поможет довезти пакет, но фурой он от этого не станет.
Минимальная безопасность
Для WebDAV-папки стоит сделать хотя бы базовую защиту:
- использовать только HTTPS;
- закрыть доступ Basic Auth паролем;
- не использовать простые пароли;
- не индексировать папку поисковиками;
- ограничить доступ по IP, если это возможно;
- делать резервные копии файлов;
- не хранить в публичной папке лишнее;
- не давать WebDAV-доступ туда, где лежит WordPress.
В Nginx для защиты от индексации можно добавить:
add_header X-Robots-Tag "noindex, nofollow, noarchive" always;
А для отключения кэша:
add_header Cache-Control "private, no-store, no-cache, must-revalidate" always;
Если доступ нужен одному или двум людям, можно дополнительно ограничить IP. Но тут надо учитывать реальность: у пользователей часто динамический адрес, мобильный интернет, домашний роутер и ещё пара сюрпризов. Без фанатизма, но с головой.
Автоматический бэкап файла
Если через WebDAV редактируется важный файл, стоит делать регулярные резервные копии. Особенно если это .accdb, который можно случайно перезаписать, повредить или закрыть неудачно.
Создадим папку для резервных копий:
sudo mkdir -p /root/example-db-backups
Простой скрипт:
sudo tee /usr/local/sbin/example-db-backup.sh >/dev/null <<'BASH' #!/usr/bin/env bash set -euo pipefail SRC="/srv/example-db/newbd.accdb" DST="/root/example-db-backups" mkdir -p "$DST" if [ -f "$SRC" ]; then cp "$SRC" "$DST/newbd.accdb.$(date +%F-%H%M%S).bak" fi find "$DST" -type f -name "newbd.accdb.*.bak" -mtime +30 -delete BASH sudo chmod +x /usr/local/sbin/example-db-backup.sh
Задача cron:
30 3 * * * root /usr/local/sbin/example-db-backup.sh >/var/log/example-db-backup.log 2>&1
Так хотя бы будет шанс откатиться, если файл повредится или кто-то случайно его перезапишет. Бэкап не делает архитектуру идеальной, но без него всё гораздо веселее. В плохом смысле.
Частые проблемы
В браузере файл скачивается, а не открывается как диск
Это нормально. Браузер не обязан открывать WebDAV как сетевой диск. Для работы как с диском нужен WebDAV-клиент, например Windows WebClient.
Windows пишет «системная ошибка 67»
Чаще всего проблема в службе WebClient, URL, SSL, Basic Auth или особенностях Windows. Начинайте с проверки службы и правильности адреса.
Диск подключается, но в Проводнике его не видно
Возможно, диск был подключён из командной строки администратора. Подключите его из обычной CMD от имени пользователя.
Access создаёт файл .laccdb
Это нормально. Это lock-файл Access. После закрытия базы он обычно исчезает. Если не исчезает, значит Access или соединение закрылись неаккуратно, и это уже повод смотреть, что происходит.
Можно ли так работать нескольким пользователям
Теоретически можно пробовать, но я бы не рекомендовал. Access через WebDAV это не нормальная многопользовательская веб-система. Для пары тестов может сойти, для постоянной работы лучше делать серверную базу и веб-интерфейс.
Вывод
WebDAV на Nginx это рабочий способ дать доступ к файлам через HTTPS и подключить папку в Windows как сетевой диск. Для простых задач это удобно: загрузить файл, скачать файл, дать ограниченный доступ к отдельному каталогу.
Но важно не путать WebDAV с обычной Windows-шарой SMB. В Проводнике оба варианта могут выглядеть как диск Z:, но технически это разные протоколы.
И ещё важнее не путать WebDAV-доступ к файлу Access с полноценной веб-базой данных. Положить .accdb на сервер можно. Подключить его через WebDAV иногда тоже можно. Но если нужна стабильная работа через интернет, с ролями, формами, отчётами и нормальной защитой, это уже отдельное веб-приложение и серверная база данных.
WebDAV хороший инструмент, когда понимаешь его границы. А когда пытаешься сделать из него облачный Access, он быстро напоминает, что Windows любит не только пользователей, но и квесты.
