Webdav root '': Fs supports modtime, but modtime is missing

Help and Support
1

What is the problem you are having with rclone?

This is a follow-up from this post.

bisync seems to be working when I do

rclone bisync S20-FE-WebDAV: /local/path/Samsung-S20-FE/ -vv --progress

If I switch src and dest, then bisync will sync some of the same files every time and gives some of the output listed below. I still need to check the modtimes for these specific files to see if they are somehow incorrect and investigate them to see if there are other anomalies.

. I would mostly like to understand 2 things:

  • The difference between bisync src dest and bisync dest src
  • NOTICE: webdav root '': Fs supports modtime, but modtime is missing

Run the command 'rclone version' and share the full output of the command.

On laptop

rclone v1.74.4
- os/version: ubuntu 20.04 (64 bit)
- os/kernel: 5.4.0-192-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.26.5
- go/linking: static
- go/tags: none

On phone

rclone v1.75.0-termux
- os/version: unknown
- os/kernel: 4.19.113-27223811 aarch64)
- os/type: android
- os/arch: amd64 (ARMv8 compatible)
- go/version: go1.26.5
- go/linking: dynamic
- go/tags: noselfupdate

Which cloud storage system are you using? (eg Google Drive)

rclone serve webdav in Termux

The command you were trying to run (eg rclone copy /tmp remote:tmp)

From my laptop

rclone bisync S20-FE-WebDAV: /local/path/ -v --progress
rclone bisync /local/path/ S20-FE-WebDAV:/ --dry-run --progress

Please run 'rclone config redacted' and share the full output. If you get command not found, please make sure to update rclone.

[S20-FE-WebDAV]
type = webdav
url = http://192.168.0.100:8080
vendor = rclone

A log from the command that you were trying to run with the -vv flag

webdav root '': Fs supports modtime, but modtime is missing

This only happens with

rclone bisync /local/path/ S20-FE-WebDAV:/ --dry-run --progress

I also see

2026/08/02 11:18:41 DEBUG : Android/.Trash/com.sec.android.gallery3d/9067676529622303932.jpg: Excluded
2026/08/02 11:18:41 DEBUG : Android/.Trash/com.sec.android.gallery3d/916405891440345997.jpg: Excluded (FilesFrom Filter)

with rclone bisync /local/path/ S20-FE-WebDAV:/ --dry-run --progress
but not with

rclone bisync S20-FE-WebDAV: /local/path/ -v --progress

I have not set up any exclude files.

Could anyone give me some insight as to where the modtime is missing error comes from or the Excluded and FilesFrom Filter comes from?

2

Termux is known to have issues with times.
FYI Rclone WebDAV server (Termux) logs stat errors after file operations

3

They are completely different sessions -- with different listing filenames and potentially even different states (depending on when each was last run). They are not interchangeable, so it is not necessarily surprising that they give you different results.

Additionally, in your example command here:

The second command has --dry-run while the first does not. Another reason for possible differences.

Note also that even aside from possible differences in listing state and dry vs. not, Path1 and Path2 are not always treated as entirely symmetrical. For example, during a --resync, --resync-mode defaults to path1 unless you've specified otherwise.

The literal log notice comes from here:

What it means is that the backend (in your case, webdav with vendor = rclone) claims it supports modtimes, but in fact delivers files that don't have modtimes (or, more accurately, have a "zero" time like 0001-01-01T00:00:00Z, which is Go's default.)

This could happen if, for example, err != nil here:

(bisync doesn't actually use the vfs, but it's relevant here because you're running rclone serve webdav)

To get to the bottom of what's causing it in your particular case, it would really help to know your exact rclone serve webdav command, including your --vfs-cache-mode and --no-modtime settings (if any). It would also help to know the modtime precision that your S20-FE-WebDAV: actually returns (and whether that's different from the precision it advertises.)

While it's potentially worth investigating regardless, note that it's not what's causing the "bisync will sync some of the same files every time" issue -- they are different issues. Bisync actually returns false there (i.e. it considers the times NOT different, because it couldn't compare them and conclusively determine that they differ.)

The literal error comes from here:

but the reason you're seeing it is because bisync internally uses a files-from filter to transfer the changed files in each direction (even though you didn't specify a filter yourself):

The reason you're seeing it in one direction and not the other is because you ran one with -vv and the other with -v. The log prints at the DEBUG level, so you'll only see it with -vv.

In other words, this one is a red herring.