WebDav throwing 404 and 429 errors

Nextcloud version (eg, 20.0.5): Nextcloud Hub 6 (27.1.3)
Operating system and version (eg, Ubuntu 20.04): Linux 6.1.49-Unraid x86_64
Apache or nginx version (eg, Apache 2.4.25): ngisx
PHP version (eg, 7.4): 8.2.10

The issue you are facing: When using webdav to backup files from my Android device with Swiftbackup I keep getting 404 errors that a tmp file can’t be found and I am getting file locked errors also even though I have file locks disabled

Is this the first time you’ve seen this error? (Y/N):

Steps to replicate it:

  1. Use webdav

The output of your Nextcloud log in Admin > Logging:

Tried to get the important logs but it was too big for pastebin https://pastebin.com/X94jjb8E

The output of your config.php file in /path/to/nextcloud (make sure you remove any identifiable information!):

<?php
$CONFIG = array (
  'memcache.local' => '\\OC\\Memcache\\APCu',
  'datadirectory' => '/data',
  'instanceid' => 'redacted',
  'passwordsalt' => 'redacted',
  'secret' => 'redacted',
  'trusted_domains' => 
  array (
    0 => 'redacted',
  ),
  'dbtype' => 'mysql',
  'version' => '27.1.3.2',
  'overwrite.cli.url' => 'redacted',
  'dbname' => 'ncdb',
  'dbhost' => 'redacted',
  'dbport' => '',
  'dbtableprefix' => 'oc_',
  'mysql.utf8mb4' => true,
  'dbuser' => 'redacted',
  'dbpassword' => 'redacted',
  'installed' => true,
  'maintenance' => false,
  'mail_smtpmode' => 'smtp',
  'mail_smtpsecure' => 'tls',
  'mail_sendmailmode' => 'smtp',
  'mail_from_address' => 'Nextcloud',
  'mail_domain' => 'redacted',
  'mail_smtpauthtype' => 'LOGIN',
  'mail_smtpauth' => 1,
  'theme' => '',
  'loglevel' => 2,
  'logfile' => '/var/log/nextcloud.log',
  'logfile_audit' => 'var/log/nextcloud_audit.log',
  'filelocking.enabled' => 'false',
  'memcache.locking' => '\\OC\\Memcache\\APCu',
  'upgrade.disable-web' => true,
);

The output of your Apache/nginx/system log in /var/log/____:

Docker container didn't have these as it was rebooted.

Anyone able to help?

Hello ZerkerEOD,
maybe some more logs would help.

Could you check you web server’s logs and see if the 404’s are on paths like hidden files or similar?
Does you Nextcloud client work properly on normal files (it also uses WebDAV)? I mean, are you able to browse your folder structure using the client?

Here is some of the access log snippet for the 404 and 400’s:

redacted - redacted [12/Nov/2023:02:01:20 +0000] "PUT /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.splits%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 201 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:01:22 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:01:23 +0000] "MOVE /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.splits%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 204 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:01:24 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.splits%20%28Pixel%207%20Pro%29 HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:01:57 +0000] "DELETE /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.dat%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 404 253 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:01:58 +0000] "DELETE /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.app%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 404 253 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:01 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:02 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:19 +0000] "PUT /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.ledger.live.splits%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 201 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:19 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:20 +0000] "MOVE /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.ledger.live.splits%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 204 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:21 +0000] "HEAD /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.ledger.live.splits%20%28Pixel%207%20Pro%29 HTTP/2.0" 200 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:34 +0000] "PUT /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.dat%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 400 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

redacted - redacted [12/Nov/2023:02:02:44 +0000] "PUT /remote.php/dav/files/redacted/backup/android/SwiftBackup_b705cd3345c8e0ad/Pixel%207%20Pro/com.kubi.kucoin.app%20%28Pixel%207%20Pro%29.tmp HTTP/2.0" 400 0 "-" "SwiftBackup / 4.2.5 (569); Google/Pixel 7 Pro"

Yeah, I can go around and interact with file. It looks like the tmp files are not there which would explain the 404. Not sure about the file locks as I have that disabled.

I’m not sure what kinds of unwanted effects you can expect when Transactional file locking is set to off. A backup procedure that quickly creates and updates many temporary files may trigger some.
I would generally prefer to have that turned on instead.
That said, is your php tmp setting ok? Error 400 when uploading multiple files on stress tests concurrently with curl and webdav

Set file locking back to true. I added the option for the temp directory to be on my /data/tmp in the docker which is on my drives not my docker image but I am still getting errors, Error contacting my instance a .tmp file to the backup location and it is 404. I think it is setting its own tmp files in the location.