499 errors Syncing from Mac Client

Milner_Household · May 1, 2023, 12:52pm

Hi.

NC Version 26.0.1 Running via Docker on an ARM NAS
Connection via NGINX Reverse Proxy
Fresh Install
Mac Client (OSX 26.1.0) v 3.8.1

I decided it was time to do a fresh install and re-set up NC on the NAS as it had some legacy stuff inn there when I’d made bad decisions earlier.

Set up OK, working well via reverse proxy, good access via browser.

OSX Client seems to be able to sync directories with a relatively small number of files and data - 5MB OK in a folder.

I added an 11MB folder and received a number of “Network Error : 499” for a number of files (not particularly large files to be honest). After an exit of the client and a re-open the client seemed to manage to complete a sync.

I have now added a 120MB folder and the sync seems to be repeatedly failing on files and is not completing.

Since a 499 error seems to be a Client Closes connection I added these lines to the nextcloud.cfg

I’ve checked some of the files where the error is reported and they seem to be visible via the NC Web Client - So I’m not sure what that means.

maxChunkSize=50000000
minChunkSize=1000000

Which was suggested elsewhere.

This is my General section:

[General]
chunkSize=10000000
clientVersion=3.8.1git (build 14890)
confirmExternalStorage=true
isVfsEnabled=false
maxChunkSize=50000000
minChunkSize=1000000
newBigFolderSizeLimit=500
optionalServerNotifications=true
showCallNotifications=true
targetChunkUploadDuration=6000
updateSegment=49
useNewBigFolderSizeLimit=true

Any suggestions as to a possible setting I’m missing somewhere on the NC server?

Milner_Household · May 1, 2023, 2:31pm

I am finding many lines similar to this in the nextcloud log:

{"reqId":"some_kind_of_key","level":3,"time":"2023-05-01T14:27:12+00:00","remoteAddr":"172.20.0.2","user":"XXXX","app":"no app in context","method":"POST","url":"/remote.php/dav/bulk","message":"\"some_file_path_and_name\" is locked","userAgent":"Mozilla/5.0 (Macintosh) mirall/3.8.1git (build 14890) (Nextcloud, osx-21.6.0 ClientArchitecture: arm64 OsArchitecture: arm64)","version":"26.0.1.1","data":{"path":"some_file_path_and_name\"}}

gVes · November 25, 2023, 3:20pm

I am running a similar setup, behind Nginx RP, and docker in Ubuntu. I am however on x86, but encountered the same “Network Error: 499”.
Not sure why it’s not syncing. The files in question are small, sometimes small PDF files around 200kb.

Quite frustrating, as I have been testing NC the past 3 months before I deploy it in our office with over 200 users. Can’t do that if NC can’t handle this most basic task. Anyone else facing a similar issue?

kmwoley · September 20, 2024, 5:05am

I recently installed NC30 and the latest Windows client and was also receiving a host of 499’s in my NGINX logs.

However, my access pattern where the 499s were most common fit the pattern you describe here.

In particular, I’d get a 499 whenever the client tried to GET several (10-20) files within the same second. Client logs appeared to have only a few microseconds between the GET and the “Close connection” log entry

2024-09-18 17:48:28:506 [ debug nextcloud.sync.database C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\common\syncjournaldb.cpp:3058 ]	[ OCC::SyncJournalDb::commitInternal ]:	Transaction commit "download file start" and starting new transaction
2024-09-18 17:48:28:506 [ info nextcloud.sync.accessmanager C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\libsync\accessmanager.cpp:67 ]:	2 "" "https://nextcloud.domain.com/remote.php/dav/files/<file>" has X-Request-ID "cd92b7df-44a7-4396-b8fe-7664c449eaf9"

…

2024-09-18 17:48:28:508 [ warning nextcloud.sync.networkjob C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\libsync\abstractnetworkjob.cpp:371 ]:	Network job timeout QUrl("https://nextcloud.domain.com/remote.php/dav/files/<file>")
2024-09-18 17:48:28:508 [ warning nextcloud.sync.networkjob.get C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\libsync\propagatedownload.cpp:361 ]:	Timeout QUrl("https://nextcloud.domain.com/remote.php/dav/files/<file>")
2024-09-18 17:48:28:510 [ info nextcloud.sync.credentials.webflow C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\gui\creds\webflowcredentials.cpp:405 ]:	request finished
2024-09-18 17:48:28:510 [ warning nextcloud.sync.networkjob C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\libsync\abstractnetworkjob.cpp:223 ]:	QNetworkReply::OperationCanceledError "Connection Timeout" QVariant(Invalid)
2024-09-18 17:48:28:510 [ warning nextcloud.sync.credentials.webflow C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\gui\creds\webflowcredentials.cpp:207 ]:	QNetworkReply::OperationCanceledError
2024-09-18 17:48:28:510 [ warning nextcloud.sync.credentials.webflow C:\Users\User\AppData\Local\Temp\windows-25716\client-building\desktop\src\gui\creds\webflowcredentials.cpp:208 ]:	"Operation canceled"

Workaround
The only thing I found that fixed it was setting the client to have at most 1 parallel process. i.e. set the environment variable:

OWNCLOUD_MAX_PARALLEL=1

Doing this got rid of all of my 499 errors, but it also made file scan updates and downloads much slower. Small price to pay for stability, I suppose.