Safely Mount WebDAV on Linux: davfs2, Automounting, and a Nutstore Example

davfs2 maps a WebDAV resource into the Linux filesystem tree so ordinary programs can reach remote content by path. This is convenient, but it does not turn WebDAV into a local disk: reads and writes depend on the network and local cache, while server capabilities, locks, latency, and other clients can change outcomes.

This guide proceeds from a manual test to persistence and applies only to WebDAV resources you own or may access. Examples use unusable .invalid placeholders. Nutstore is one provider example verified against its official documentation, not an endorsement or promotion.

The complete visible 2025 source_export body is preserved at the end. It contains no real credentials or private identifiers, so it has no semantic redactions; five Markdown end-of-line spaces were normalized. Its credentials= option, broad automount promises, and advice to enable ignore_dav_header early are historical evidence only and must not be executed.

Table of Contents

Distinguish mounting, synchronization, and backup first

Goal	Suitable tool	Critical limitation
Give applications path-based access to remote files	`davfs2` or `rclone mount`	A network-filesystem view; offline, locking, caching, and latency semantics differ from a local disk
Keep an offline local copy and coordinate changes	Official provider sync client or a verified sync workflow	Conflict, deletion propagation, ignore, and version-recovery behavior is tool/provider-specific
Transfer a batch in one direction	`rclone copy` or another auditable copier	Direction, verification, retries, and retention must be defined; it is still not a backup policy
Maintain recoverable backups	An independent, versioned target with regular restore tests	A second folder in the same mount or account is not an independent backup

Deleting through a mount commonly changes the remote. The cache is neither a complete offline copy nor a restore point. Databases, VM images, mail stores, frequently rewritten large files, and workloads requiring POSIX atomicity or lock semantics need explicit application and provider support; “it mounted” is not production evidence.

Gather endpoint, identity, and compatibility facts

Before starting, record these facts from the service administrator and current official documentation:

the exact HTTPS WebDAV URL, including path and trailing-slash requirements—not a guessed share/browser URL;
account identity, generation/revocation of an app-specific password or token, and its access scope;
upload-size, request-rate, pagination, filename, locking, quota, version-history, and trash rules;
every other client that can edit the same file and who owns conflict resolution;
Linux distribution, davfs2 source/version, init system, and maintenance owner;
cache-space needs, log/cache retention, backup, and a verifiable rollback window.

Stop without a dedicated test directory, revocable credential, independent verification route, and restorable backup. Do not use the production root as a first test.

Verify the distribution package and version before installation

Use a package supported by the current distribution, never a random script, mirror, or old blog. These commands only inventory state; a missing package or binary is a fact to resolve, not bypass:

apt-cache policy davfs2
dnf info davfs2
mount.davfs --version

An administrator can use apt install davfs2 on Debian/Ubuntu or the current repository's dnf install davfs2 flow on Fedora/RHEL. An installation prompt about non-root mounts is an authorization decision, not an unconditional “Yes.” An ordinary-user mount requires an administrator-approved /etc/fstab entry, any distribution-required davfs2 group membership, and that user's own secrets file.

Choose the mounting identity and local ownership

One mount represents one WebDAV credential. uid, gid, file_mode, and dir_mode control only the local view; the server still sees one WebDAV user, and other clients do not inherit those local permissions.

Prefer a personal mount in that user's home, mounted and unmounted by that user. A shared service mount needs a dedicated service identity and administrator-owned system secret. Do not duplicate one app password across user-readable locations or use users to let anyone unmount unless the risk and credential-exposure boundary is explicitly approved.

Create an empty private test mountpoint and user configuration directory:

for path in "$HOME/mnt/webdav-test" "$HOME/.davfs2"; do
  test ! -L "$path" || { printf 'Stop: symlink path: %sn' "$path" >&2; exit 1; }
done
install -d -m 700 -- "$HOME/mnt/webdav-test" "$HOME/.davfs2"

The mountpoint must be the expected empty directory, not a cover over existing files. Record id output and use names rather than assuming 1000; if root mounts with uid/gid, first confirm that the dedicated identity exists.

TLS and endpoint authenticity

Use only the officially documented https:// hostname. davfs2 normally relies on the system CA store to validate certificate lifetime and hostname. On failure, do not permanently accept an unknown certificate interactively or disable validation. A private CA must be distributed through an independent trusted administrator route with update and revocation ownership.

Before sending credentials, a non-authenticated TLS probe is possible; first confirm that local OpenSSL supports the options:

openssl s_client -connect dav.example.invalid:443 -servername dav.example.invalid -verify_hostname dav.example.invalid -verify_return_error -brief </dev/null

Success proves only that the certificate chain and hostname validated on that connection, not that the WebDAV path, account, or write rights work. Stop on hostname mismatch, unknown CA, expiry, HTTPS downgrade, cross-domain redirect, captive proxy, or bad system time.

Nutstore as one verified provider example

Nutstore's help center currently documents https://dav.jianguoyun.com/dav/ as its WebDAV endpoint. The username is the Nutstore account, while the password must be a separate app password generated under third-party application management—not the account sign-in password. Give each client its own named app password so it can be revoked independently.

The official page also lists request-rate, listing, and file-size limits. These can vary by plan or time, so recheck them on deployment day rather than hard-coding them as permanent facts. If the official endpoint, identity policy, or limits differ, the current official page and your contract/administrator win. Never paste the app password into a command, ticket, screenshot, or article example.

User-level secrets file: correct syntax and mode

Prefer ~/.davfs2/secrets for a user mount. Ensure the target is not a symlink, then create or tighten its permissions without printing it:

umask 077
test ! -L "$HOME/.davfs2" || { printf 'Stop: symlink path: %sn' "$HOME/.davfs2" >&2; exit 1; }
test ! -L "$HOME/.davfs2/secrets" || { printf 'Stop: symlink path: %sn' "$HOME/.davfs2/secrets" >&2; exit 1; }
touch -- "$HOME/.davfs2/secrets"
chmod 600 -- "$HOME/.davfs2/secrets"
stat -c '%U %G %a %n' -- "$HOME/.davfs2/secrets"

Add one line with a local editor. The first field can be the exact mountpoint from /etc/fstab, scoping the credential to that mount:

/home/example-user/mnt/webdav-test user@example.invalid "APP_PASSWORD_FROM_PROVIDER"

Replace the entire placeholder line locally with the real absolute mountpoint, account, and app password. Spaces, tabs, #, backslashes, or quotes must follow the installed davfs2.conf(5) quotation/escaping rules; do not improvise. User secrets must belong to that user with mode 600; /etc/davfs2/secrets must be root-only.

davfs2 looks in user secrets, then system secrets, then prompts interactively. Current mount.davfs(8) has no general credentials=/path mount option: do not import that syntax from CIFS or another filesystem. username= is explicitly for pam_mount, should not appear in fstab, and is visible in the process list.

Begin with a noauto, single-user fstab entry

An ordinary-user mount first needs an exact administrator-approved /etc/fstab record. This remains an unusable template; its URL, user-home directory, and mountpoint must match official and secrets values exactly:

https://dav.example.invalid/webdav/ /home/example-user/mnt/webdav-test davfs noauto,user,_netdev 0 0

noauto prevents boot mounting. user lets only the mounting user unmount and implies noexec,nosuid,nodev. _netdev declares a network dependency. Upstream does not recommend users by default because it lets any user unmount.

The administrator should create a non-overwriting fstab backup, add only this line through sudoedit, and validate statically. Do not test with mount -a, which activates every eligible entry:

fstab_backup=/etc/fstab.before-davfs2
sudo test ! -e "$fstab_backup" && sudo test ! -L "$fstab_backup" || { printf 'Stop: backup path already existsn' >&2; exit 1; }
sudo cp -a -- /etc/fstab "$fstab_backup"
sudo cmp -s -- /etc/fstab "$fstab_backup" || { printf 'Stop: fstab backup verification failedn' >&2; exit 1; }
sudoedit /etc/fstab
findmnt --verify --verbose

Add only the approved user to the distribution's davfs2 group flow and start a new login session. Then mount as that user using the exact mountpoint—never a command containing URL, username, or password:

mount "$HOME/mnt/webdav-test"
findmnt --target "$HOME/mnt/webdav-test" --output TARGET,SOURCE,FSTYPE,OPTIONS

If a credential prompt appears, stop and verify the absolute mountpoint, owner, mode, and exact fstab match. Do not repeatedly guess passwords and lock the account.

Perform one read/write check in a dedicated remote directory

First read one small non-sensitive file and compare the directory through the provider web UI or another verified client. After write permission is confirmed, create one uniquely named probe only in the dedicated test directory:

probe_name="davfs2-probe-$(date -u +%Y%m%dT%H%M%SZ)-$$.txt"
local_probe=$(mktemp "$HOME/davfs2-probe.XXXXXX")
printf 'davfs2 controlled proben' > "$local_probe"
cp -- "$local_probe" "$HOME/mnt/webdav-test/$probe_name"
cmp -- "$local_probe" "$HOME/mnt/webdav-test/$probe_name"
rm -- "$HOME/mnt/webdav-test/$probe_name"
rm -- "$local_probe"

Record the probe name. Stop on any failure and retain the name for precise cleanup. cmp may read from cache, so independently confirm that the remote object appears and is later removed. A whole-directory copy, production rename, or concurrent multi-client edit is not a first test.

Close every consumer and cleanly unmount while the network still works:

sync
umount "$HOME/mnt/webdav-test"
findmnt --target "$HOME/mnt/webdav-test"

The final command returning no mount record is the expected result. If unmount blocks, do not immediately use lazy/force unmount, kill the daemon, or delete cache. Stop new writes, preserve the exact error, and reconcile pending uploads plus lost+found under the installed manual/administrator recovery procedure.

fstab options belong to different interpretation layers

Option	Interpreter	Exact boundary
`noauto` / `user` / `users`	mount/davfs2	`user` limits unmounting to the initiator; `users` is broader and usually discouraged
`_netdev`	davfs2 and boot system	Declares network dependence; does not prove DNS, authentication, or remote availability
`uid` / `gid` / `file_mode` / `dir_mode`	davfs2	Changes only the local view; only root may select another owner
`nofail`	systemd fstab generator on systemd hosts	Boot does not require mount success; runtime I/O errors remain visible
`x-systemd.automount` / `x-systemd.idle-timeout=`	systemd fstab generator	Creates on-demand automount/idle unmount; first access can still wait or fail
`credentials=`	Not a davfs2 option	Remove it; davfs2 reads defined/default secrets files

Always consult the installed versions of mount.davfs(8), davfs2.conf(5), fstab(5), and init documentation. An unknown option must not enter production on the assumption it will be ignored.

systemd on-demand mounting and boot boundaries

Only on a systemd host whose manual confirms support, and only after the manual test passes, may an administrator consider this system-service template:

https://dav.example.invalid/webdav/ /srv/webdav-example davfs rw,_netdev,nofail,x-systemd.automount,x-systemd.idle-timeout=5min,uid=webdavsvc,gid=webdavsvc,file_mode=0600,dir_mode=0700 0 0

This is an alternative to the user mount. It requires a real dedicated webdavsvc identity, a matching root-only /etc/davfs2/secrets entry, and a private mountpoint. Do not keep user and system variants simultaneously or copy the user secret into the system file.

x-systemd.automount delays the mount attempt until path access; nofail means boot does not require the actual mount; _netdev creates network-mount dependencies. They do not guarantee correct network-online configuration and cannot keep the first ls from blocking. Check semantics in the installed version:

systemd --version
man systemd.mount
man systemd.automount

After editing, run findmnt --verify --verbose and systemctl daemon-reload, trigger only this mountpoint, and simulate DNS failure, no network, revoked credentials, reboot, and shutdown. A critical service must not assume unconditional remote availability; give it explicit timeouts and an application-level degraded mode.

Cache, locks, offline work, and conflicts

davfs2 caches directories/attributes in memory and holds a disk copy of every open file. Local cache space is therefore required, and another client's directory changes can appear late. Upload can be delayed after close, so a locally successful write while offline is not proof of remote acknowledgement.

WebDAV locks are not a strong consistency guarantee. A server might lack locks, a lock can expire, the network can prevent refresh, and another client can use different semantics. Upstream says that when a local modification cannot be safely uploaded, davfs2 can leave it in cache lost+found; this needs human reconciliation and is neither backup nor automatic conflict resolution.

Keep the default use_locks 1. Do not disable locks or weaken caching/validation to “improve performance” without reproducible evidence, known server semantics, and concurrency tests. Do not let the official sync client, davfs2, and another WebDAV client write the same file concurrently.

Diagnostic order and stop conditions

Symptom	Check first	Do not
TLS or redirect error	Official endpoint, final host, certificate chain/hostname, time, proxy	Accept unknown certificate, downgrade to HTTP, disable checks
`401`/`403`	App password, identity, permission scope, revocation/lockout	Guess repeatedly, use the account password, put credentials in argv
“server does not support WebDAV”	URL path, WebDAV enablement, HTTP status/DAV capability, server logs	Begin with `ignore_dav_header 1`
Delayed file or conflict	Cache space, pending upload, lock, second client, `lost+found`	Delete cache, force-unmount, overwrite remote versions
Boot or first access hangs	`_netdev`, automount, network-online implementation, timeout, DNS	Claim `nofail` guarantees application availability
Wrong permissions	Actual mounter, `uid`/`gid`, local mode, remote-account rights	Recursively `chmod`/`chown` the mount expecting server ACL changes

ignore_dav_header remains an upstream-supported but default-off compatibility switch. It applies only when evidence shows that the server reports capabilities incorrectly in its DAV response header. Only after the provider/server owner confirms that fact, all path/TLS/authentication issues are excluded, and an isolated test passes may it be scoped temporarily in user davfs2.conf:

[/home/example-user/mnt/webdav-test]
ignore_dav_header 1

It cannot repair a wrong URL, authorization, TLS, locking, or broken WebDAV implementation. Record the original response, version, and owner; remove the section if validation fails. Never enable debug secrets on a real account: upstream says it emits normally obscured confidential data. Ordinary logs may still contain URL, username, paths, and filenames; view only a narrow interval and redact before sharing:

journalctl --since "15 minutes ago" --no-pager _COMM=mount.davfs

When to choose the provider client or rclone

Prefer evaluating the official provider client when you need a complete offline copy, provider version history, a conflict UI, or selective sync. For auditable transfers or another WebDAV implementation, use rclone's official WebDAV backend. rclone mount is still a network mount, not automatic synchronization or backup.

Create an isolated test remote through interactive rclone config, protect its config as mode 600, and never pass a password in argv or the environment. An rclone-obscured password is not strong encryption and remains a secret. Initial read-only inventory and copy/sync previews can use:

rclone config
rclone lsd webdav-test:
rclone copy --dry-run /path/to/controlled-source webdav-test:controlled-destination
rclone sync --dry-run /path/to/controlled-source webdav-test:controlled-destination

copy and sync differ: a real sync can delete destination content to match the source. Remove --dry-run only after reviewing the complete preview, filters, direction, verification, version retention, and rollback. Never let rclone and davfs2 modify the same test path together.

Rollback, revocation, and acceptance checklist

Rollback order is: stop new writes, close consumers, record pending probes/cache conflicts, cleanly unmount while online, then remove only this fstab line and run systemctl daemon-reload. Compare the known-good fstab backup before restoring it so later administrator changes are not overwritten. Finally revoke this client's app password at the provider and remove its exact secrets line; do not print a secret as evidence.

Before retirement, confirm no mount, automount, open process, pending upload/lost+found, or test object remains. Retain only redacted version, time, error code, and recovery result—not credentials or full private paths.

The WebDAV URL, TLS final host, and provider identity come from current official sources.
A unique revocable app password is used; no account password, argv, URL, or log leakage exists.
Exactly one user/system mount design is active, with matching mountpoint, owner, secrets, and permissions.
fstab has no credentials=/username=; installed manuals confirm every davfs2 and systemd option.
A noauto manual test preceded independent remote verification and a clean unmount.
Cache space, locks, concurrency, outage, revocation, reboot, first access, and shutdown were tested.
ignore_dav_header remains off by default; any exception has server evidence, narrow scope, and rollback.
Sync, mount, and independent versioned backup each have a defined tool, direction, owner, and restore test.

References

Historical source archive

The following is the complete inert archive of the visible 2025 source_export body. It contained no real password, private account, or tracking parameter, so no semantic value was replaced. Exactly five end-of-line spaces were removed for repository validation; the body, blank lines, generated contents remnant, code, and links are otherwise unchanged. The HTTP link, credentials=, automount promise, and ignore_dav_header advice inside the fence are historical evidence only and must not be executed.


WebDAV（Web Distributed Authoring and Versioning）是一种允许通过 HTTP 协议将远程存储挂载到本地文件系统的技术。通过它，你可以像操作本地目录一样对远程文件进行 `ls`、`cp`、`mv` 等操作。本文将介绍如何在 Linux 系统中安装和配置 **davfs2**，并以坚果云（Nutstore / 坚果云）为例，演示挂载 WebDAV 目录的全过程。

---

Table of Contents

Toggle

- [一、前言](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E4%B8%80%E3%80%81%E5%89%8D%E8%A8%80)
- [二、安装 davfs2](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E4%BA%8C%E3%80%81%E5%AE%89%E8%A3%85_davfs2)

  - [1. Debian/Ubuntu 系列](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#1_DebianUbuntu_%E7%B3%BB%E5%88%97)
  - [2. RHEL/CentOS/Fedora 系列](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#2_RHELCentOSFedora_%E7%B3%BB%E5%88%97)

- [三、创建挂载点目录](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E4%B8%89%E3%80%81%E5%88%9B%E5%BB%BA%E6%8C%82%E8%BD%BD%E7%82%B9%E7%9B%AE%E5%BD%95)
- [四、配置 davfs2](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E5%9B%9B%E3%80%81%E9%85%8D%E7%BD%AE_davfs2)

  - [4.1 配置登录凭证](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#41_%E9%85%8D%E7%BD%AE%E7%99%BB%E5%BD%95%E5%87%AD%E8%AF%81)
  - [4.2 修改 davfs2.conf（可选）](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#42_%E4%BF%AE%E6%94%B9_davfs2conf%EF%BC%88%E5%8F%AF%E9%80%89%EF%BC%89)

- [五、手动挂载测试](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E4%BA%94%E3%80%81%E6%89%8B%E5%8A%A8%E6%8C%82%E8%BD%BD%E6%B5%8B%E8%AF%95)
- [六、在 /etc/fstab 中自动挂载](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E5%85%AD%E3%80%81%E5%9C%A8_etcfstab_%E4%B8%AD%E8%87%AA%E5%8A%A8%E6%8C%82%E8%BD%BD)
- [七、常见问题及解决方案](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E4%B8%83%E3%80%81%E5%B8%B8%E8%A7%81%E9%97%AE%E9%A2%98%E5%8F%8A%E8%A7%A3%E5%86%B3%E6%96%B9%E6%A1%88)
- [八、总结](https://blog.lazying.art/en/html/computer_internet/unix_linux/ubuntu/3087/%e4%bd%bf%e7%94%a8-davfs2-%e5%9c%a8-linux-%e4%b8%8a%e6%8c%82%e8%bd%bd-webdav-%e7%bd%91%e7%9b%98%ef%bc%88%e4%bb%a5%e5%9d%9a%e6%9e%9c%e4%ba%91%e4%b8%ba%e4%be%8b%ef%bc%89.html/#%E5%85%AB%E3%80%81%E6%80%BB%E7%BB%93)

## 一、前言

坚果云（Nutstore）是一款常用的云存储服务，提供了 WebDAV 访问接口。通过使用 **davfs2**，我们可以在 Linux 系统中直接将坚果云的远程存储挂载到本地文件夹，实现与本地磁盘类似的管理方式。

---

## 二、安装 davfs2

### 1. Debian/Ubuntu 系列

sudo apt update
sudo apt install davfs2


在安装过程中，系统可能会提示你是否允许非 root 用户挂载 WebDAV 文件系统。如果你希望普通用户也可以挂载，选择 **Yes**（或相应的选项）。

### 2. RHEL/CentOS/Fedora 系列

sudo yum install davfs2


或在新版本的 Fedora / RHEL 上使用：

sudo dnf install davfs2


---

## 三、创建挂载点目录

在本地创建一个用于挂载坚果云的目录，例如：

sudo mkdir -p /mnt/nutstore


这个目录将作为本地与坚果云之间的“桥梁”。

---

## 四、配置 davfs2

### 4.1 配置登录凭证

如果坚果云的 WebDAV 访问需要用户名和密码，可以在 `/etc/davfs2/secrets` 文件中添加：

sudo nano /etc/davfs2/secrets


在文件末尾写入以下内容（将示例 URL 和用户名、密码替换为你的实际信息）：

https://dav.jianguoyun.com/dav <你的用户名> <你的密码>


保存后，为了安全起见，确保只有 root 或相应用户可读该文件：

sudo chmod 600 /etc/davfs2/secrets


### 4.2 修改 davfs2.conf（可选）

部分服务器（或云服务）可能对 WebDAV 协议支持不完全，导致出现类似

mount.davfs: mounting failed; the server does not support WebDAV


的错误。这种情况下，你可以尝试在 `/etc/davfs2/davfs2.conf` 中添加：

ignore_dav_header 1


以忽略特定的协议头检查，从而兼容某些非标准 WebDAV 服务。

---

## 五、手动挂载测试

在配置好后，你可以先进行手动挂载测试。以下以坚果云的 WebDAV 地址为例（有时需要在末尾加 `/`）：

sudo mount -t davfs https://dav.jianguoyun.com/dav /mnt/nutstore


如果配置正确，系统会提示输入凭据（或自动读取 `/etc/davfs2/secrets`），成功后你可以使用以下命令检查：

df -h | grep nutstore
ls /mnt/nutstore


若能列出远程文件，说明挂载成功。

---

## 六、在 /etc/fstab 中自动挂载

如果希望开机自动挂载或在执行 `sudo mount -a` 时自动挂载，可以在 `/etc/fstab` 中添加如下条目（示例）：

https://dav.jianguoyun.com/dav /mnt/nutstore davfs rw,uid=1000,gid=1000,_netdev,users,credentials=/etc/davfs2/secrets 0 0


- **rw**：读写方式挂载
- **uid=1000,gid=1000**：指定挂载后文件的属主和属组（请根据实际用户 ID、组 ID 修改）
- **_netdev**：表示这是一个网络文件系统，系统会在网络启动后再尝试挂载
- **users**：允许非 root 用户执行挂载/卸载
- **credentials**：指定存储 WebDAV 登录凭据的文件

添加完毕后，使用：

sudo mount -a


来测试。如果无报错且能正常访问 `/mnt/nutstore`，说明自动挂载已配置成功。

---

## 七、常见问题及解决方案

1. **“the server does not support WebDAV”**

  - 确认坚果云或其他服务端已开启 WebDAV 功能，并且 URL 正确（可能需要在末尾加 `/`）。
  - 在 `/etc/davfs2/davfs2.conf` 中尝试添加 `ignore_dav_header 1`。
  - 检查网络是否通畅，以及是否有防火墙阻止。

2. **需要频繁输入用户名/密码**

  - 确保 `/etc/davfs2/secrets` 已正确配置并权限设置为 `600`。
  - 若使用的是用户级配置，可以改在 `~/.davfs2/secrets` 中保存凭据。

3. **权限问题**

  - 挂载后若无法读写文件，需检查 fstab 中的 `uid`、`gid` 选项，或将用户添加到 `davfs2` 组。
  - 也可使用 `chown` 或 `chmod` 来调整访问权限。

4. **网络启动顺序**

  - 使用 `_netdev` 选项可确保系统在网络就绪后再挂载。
  - 若仍有启动顺序问题，可考虑使用 systemd 的 `After=network-online.target` 等机制。

5. **替代方案**

  - 若坚果云的 WebDAV 不兼容或不稳定，可以使用 **rclone** 等工具，通过其对坚果云的支持进行挂载或同步。

---

## 八、总结

通过 **davfs2**，你可以轻松地将坚果云（Nutstore）等支持 WebDAV 的云盘服务挂载到 Linux 本地，享受与本地磁盘类似的文件操作体验。若遇到不标准的 WebDAV 实现或连接问题，可尝试 `ignore_dav_header 1` 或使用其他工具（如 rclone）来辅助挂载。

在正确配置后，每次系统启动都会自动加载远程存储，你可以随时访问、编辑和管理云端文件，无需手动登录网页或使用额外的同步客户端。这为多平台文件管理、服务器远程办公等场景带来了极大的便利。

---

**进一步阅读与参考：**

- [davfs2 官方文档](http://savannah.nongnu.org/projects/davfs2/)
- [坚果云官方文档](https://help.jianguoyun.com/)
- [rclone 文档](https://rclone.org/)

希望本教程能帮助你更好地将坚果云等 WebDAV 服务整合到 Linux 系统中，若有疑问或需要更多配置示例，欢迎在评论区留言或参考官方文档。祝你使用愉快！