Closed bruennlein closed 1 year ago
Just woke up to this issue this morning. Had the android client set up for months, working flawlessly. Yesterday I fiddled with the server config.php (in docker) in order to get the desktop client authentication to work. That works now, browser client also works, but the android client thinks the server is in maintenance mode. I removed and added the user back, still thinks it's in maintenance mode.
EDIT: Clear Storage / Clear Cache used (stored data never got to 0). Tried to add my account again, app would continuously demand pin after getting pin. Finally uninstalled app, installed it back and the issue is fixed for me.
I've been having this issue on Android since updating to nextcloud 19. I have my phone's camera directory configured to automatically upload to an S3 remote mount folder within nextcloud. I have set "move to nextcloud directory" in the sync options. Uploads regularly fail in this configuration, I'm not sure why. But I get this "maintenance mode" notification every few minutes since the update to nextcloud 19. Unfortunately, reinstalling the Android app does not fix the issue, nor does clearing failed uploads, nor does the trick mentioned above of disabling internet access for a period.
I'm having this issue with the android dev version of the app (build 20200610) and a fresh install of Nextcloud 19
I also tried this on a previous android build from 20200513 with the same results
Although for me I can't even log it.
mobile brave logs in fine.
Additionally desktop sync clients don't have a problem logging in and neither do browsers on a regular desktop
Indications are that this is related to NAT reflection on the LAN. So using an external valid URL while connected to wifi causes the android client to throw this error
It seems to affect Nextcloud but not Confluence on the same LAN with the same NAT reflection
I can confirm this is an android issue as the iOS clients (both Safari and the app) connect fine behind NAT reflection
I was able to login with the 20200620 version of nextcloud-dev from F-Drdoid market with no other changes made
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
.
Still experiencing the problem, >1 year after the issue was opened.
Any help from the developers would be great. We're trying to wrap our heads around possible causes and solutions, but it's hard to find a solution if developers aren't really investigating the issue and there's a bot that randomly closes this issue every couple of days
What I have seen this is sync problem what come when file upload process get interrupted it can get stuck. Usuallu that failure mode goes away in some days. But still it is quite annoying.
Any help from the developers would be great.
I tried…But I have no ideas left. And it is working for most users, which makes it even harder to narrow it down (and also moves a bit back in priority list, due to man power…)
Any help from the developers would be great.
I tried…But I have no ideas left. And it is working for most users, which makes it even harder to narrow it down (and also moves a bit back in priority list, due to man power…)
If it can help, this is the type of output I most commonly see on my NextCloud instance whenever I get the error (it doesn't happen only with auto-upload, it also occurs with regular uploads):
{"reqId":"******","level":3,"time":"2020-09-07T16:52:21+00:00","remoteAddr":"10.8.0.1","user":"blacklight","app":"PHP","method":"MOVE","url":"/nextcloud/remote.php/dav/uploads/blacklight/abcdefabcdef/.file","message":"Cannot modify header information - headers already sent by (output started at /var/www/nextcloud/3rdparty/sabre/http/lib/Sapi.php:132) at /var/www/nextcloud/apps/dav/lib/Connector/Sabre/File.php#680","userAgent":"Mozilla/5.0 (Android) Nextcloud-android/3.13.0","version":"19.0.2.2"}
I guess that there's some issue with headers sent twice?
@BlackLight this is indeed helpful, which indicates that some sort of server <-> Android is working wrong.
@nextcloud/server-triage can you help us here with the "Cannot modify header information" error?
Any help from the developers would be great.
I tried…But I have no ideas left. And it is working for most users, which makes it even harder to narrow it down (and also moves a bit back in priority list, due to man power…)
Have you been unable to reproduce the problem for testing?
For me, its pretty easy to reproduce, by breaking a WIFI connection during an upload (and having the app set to only upload on WIFI) - especially with large files and/or a slow WIFI connection, so you can be sure you break the upload in the middle.
@nextcloud/server-triage can you help us here with the "Cannot modify header information" error?
https://github.com/nextcloud/server/issues/22509. I think the warning is not related to this issue.
"MOVE","url":"/nextcloud/remote.php/dav/uploads/blacklight/abcdefabcdef/.file",
it occurs exactly when trying to finish chunked upload. I had something similar on other systems (not NC related) and then the return was different, so I would suspect that something adds an header and thus this warning is returned with the result of move operation and thus NC app does not accept it.
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!
"MOVE","url":"/nextcloud/remote.php/dav/uploads/blacklight/abcdefabcdef/.file",
Another reason why the above request could fail is that sometimes requests to files starting with a dot (aka hidden files) are blocked: https://github.com/nextcloud/server/issues/8802 / https://github.com/nextcloud/documentation/pull/1748.
If I'm reading the leading dot issue right, its only an nginx issue, I'm running on apache. So I don't think its the (only) thing going on with this issue.
How long before this issue is fixed, it's been over a year now. Lots of debug info is provided, please fix.
As we do a regular upload on Android's side I suspect that this is a server issue or a server configuration problem, therefore I transfer this to server repo.
Note, there is another issue open on the nextcloud server already: #16383
got the same issue after migrating from nextcloud snap to docker (nginx, php-fpm, pgsql) and updating to 21.0.0. seems like the requests from the app get a 503 http-error on /remote.php
logs from nextcloud:fpm-alpine
172.30.0.3 - 02/May/2021:13:23:23 +0000 "GET /index.php" 204
172.30.0.3 - [user] 02/May/2021:13:23:24 +0000 "HEAD /remote.php" 503
172.30.0.3 - [user] 02/May/2021:13:23:25 +0000 "PUT /remote.php" 503
172.30.0.3 - 02/May/2021:13:23:26 +0000 "GET /index.php" 204
172.30.0.3 - [user] 02/May/2021:13:23:26 +0000 "HEAD /remote.php" 503
172.30.0.3 - [user] 02/May/2021:13:23:27 +0000 "MKCOL /remote.php" 503
172.30.0.3 - [user] 02/May/2021:13:23:27 +0000 "PROPFIND /remote.php" 503
Seems like you have to have to enable https behind a reverse proxy. Otherwise dav applications, like the android/desktop client, calendars, contacts etc., will not work. Just adding the X-Forwarded-Proto
-Header wont work either.
In my case (I'm using the php-fpm image) I just passed /etc/letsencrypt/
to the nginx container:
- /etc/letsencrypt/:/etc/letsencrypt/:ro
And added
ssl_certificate /etc/letsencrypt/live/domain/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain/privkey.pem;
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
fastcgi_param HTTPS on;
to the vHost in nginx.conf
.
I still consider this a bug, as ssl behind a proxy is unnecessary in most cases. At least when X-Forwarded-Proto
is set to https it should work.
You don't need to do that (thus no bug) but you need to tell it to Nextcloud in its server config file.
alright. it's working now. I thought setting overwrite.cli.url
to https://foo.bar
would be enough.
I just added this to the config now:
'trusted_proxies' => ['172.17.0.1'],
'overwritehost' => 'foo.bar',
'overwriteprotocol' => 'https',
I had the same (or a similar) issue, I guess it's due to Nextcloud thinking that a file exists, while it doesn't exist on the filesystem. Probably due to a broken upload (I had it with quite large videos, that might got interrupted during an upload).
I could fix this by running ./occ files:scan --all
, and retrying the upload on my mobile. It all went fine then.
The issue that should be solved here is that nextcloud should return a sane error instead of "server is in maintenance mode". Actually, a check could be made to see if the file exist on the filesystem before throwing the error. If the file isn't there, why refuse the upload? Just let the upload continue and everything will be fine.
Things I tried:
Details: NextCloud version 22.1.0 running in the official container on unraid Android app version 3.16.1 from FDroid
Some additional investigation into this issue also happened in a parallel bug: #16383
I've also been having that problem for a long time now. Happened on an Android 7 phone just like it's now happening on an Android 11 one (everything works fine via the webinterface).
I've had a look at the nextcloud.log file on the server. Those 2 entries are repeated at every sync attempt: Log.txt
Android app version: 3.17.0 Server version: 21.0.4 (on a self installed Debian 11.0 server, but occurred on 10.X as well)
I've seen this problem a few times, and gathered some information today.
The Android app erroneously refuses to upload a file because the server is in "Maintenance Mode".
Historically it has been difficult to get the file to upload (IIRC, tapping the bin and trying a manual upload via the app, to the same location, doesn't work either).
v3.17.1
v21.?
and updated to v22.2.0
(which didn't resolve it - using the docker container behind Traefik).On disk, the /var/www/html/data/attie/uploads/f3412c2a7b72dc1d34716093dd216f63/
directory exists, but is empty (i.e 0000000000000000-0000000004255266
does not exist, and there are no hidden / dot-files).
As this appears to be a WebDAV MOVE
operation, I tried copying the original file from my phone to .../0000000000000000-0000000004255266
, pressed retry, and it completed successfully - the file is now available in the Nextcloud Web UI.
Reading into this a bit, I imagine there are a few steps to placing a file on the Nextcloud server - importantly PUT and MOVE... I'd guess that there is a race condition or logic error somewhere that means the app and/or server believe that the file has been uploaded and is in place, but in fact it was either lost (i.e: failed move at filesystem level?) or never actually existed on the server.
MOVE
- rmdir()
fails because directory is not emptyPUT
- fails because took 4255266
bytes from client, but only wrote 3022848
bytes (original file is 4255266
bytes)
MOVE
- fopen()
fails because the file doesn't exist(?)PUT
- fails because took 4255266
bytes from client, but only wrote 2834432
bytesMOVE
- fopen()
fails because the file doesn't exist(?)MOVE
- fopen()
fails because the file doesn't exist(?)MOVE
- fopen()
fails because the file doesn't exist(?)I noticed other stale files in the uploads directory. These are larger / videos, and appear to be in 10MB-ish (10240000 bytes) chunks... I suspect that these may relate to previous failures I've seen, and the log has the same error (e.g: "Expected filesize of 10240000 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 6389760 bytes."), but these only seem to have one PUT
attempt...
Some questions or areas to investigate further:
Sabre\DAV\Exception\ServiceUnavailable
), which is what we appear to be getting, and which is likely what is producing the erroneous "Maintenance Mode" message.It's just happened again... more info below.
Doing some further after-the-fact analysis... looking at the Apache access.log
, I can see:
172.21.0.12 - attie [13/Nov/2021:18:12:48 +0000] "MKCOL /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 201 548 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:12:48 +0000] "PROPFIND /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 207 1062 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:12:48 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000000000000-0000000010239999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:12:58 +0000] "MKCOL /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 405 895 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:12:58 +0000] "PROPFIND /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 207 1078 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:12:58 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000010240000-0000000020479999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:02 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000020480000-0000000030719999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:05 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000030720000-0000000040959999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:10 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000040960000-0000000051199999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:14 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000051200000-0000000061439999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:19 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000061440000-0000000071679999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:23 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000071680000-0000000081919999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:28 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000081920000-0000000092159999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:33 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000092160000-0000000102399999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:38 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000102400000-0000000112639999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:42 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000112640000-0000000122879999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:47 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000122880000-0000000133119999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:51 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000133120000-0000000143359999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:13:56 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000143360000-0000000153599999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:00 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000153600000-0000000163839999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:05 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000163840000-0000000174079999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:09 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000174080000-0000000184319999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:14 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000184320000-0000000194559999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:18 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000194560000-0000000204799999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:23 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000204800000-0000000215039999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:27 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000215040000-0000000225279999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:32 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000225280000-0000000235519999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:36 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000235520000-0000000245759999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:40 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000245760000-0000000255999999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:44 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000256000000-0000000266239999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:49 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000266240000-0000000276479999 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:54 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000276480000-0000000285398984 HTTP/1.1" 201 730 "-" "Mozilla/5.0 (Android) Nextcloud-andro
172.21.0.12 - attie [13/Nov/2021:18:14:57 +0000] "MOVE /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/.file HTTP/1.1" 403 944 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:12:52 +0000] "PUT /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/0000000010240000-0000000020479999 HTTP/1.1" 400 1010 "-" "Mozilla/5.0 (Android) Nextcloud-andr
172.21.0.12 - attie [13/Nov/2021:18:16:01 +0000] "MKCOL /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 405 895 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:16:01 +0000] "PROPFIND /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 207 1370 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:16:01 +0000] "MOVE /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/.file HTTP/1.1" 503 808 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:18:22 +0000] "MKCOL /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 405 895 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:18:22 +0000] "PROPFIND /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408 HTTP/1.1" 207 1370 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
172.21.0.12 - attie [13/Nov/2021:18:18:22 +0000] "MOVE /remote.php/dav/uploads/attie/f33f7f89afc28b2042f894644325a408/.file HTTP/1.1" 503 808 "-" "Mozilla/5.0 (Android) Nextcloud-android/3.17.1"
Note that PUT
of 0000000010240000-0000000020479999
that gets a 400 response, and the timestamp for which is very out of order. I believe that Apache will stamp log entries on the start of the request... so it comes shortly before the other PUT
of 0000000010240000-0000000020479999
, and times out (or something) after approx 3m09s.
This also approximately correlates with the Expected filesize of 10240000 bytes but read (from Nextcloud client) and wrote (to Nextcloud storage) 6025216 bytes.
error message, which is timestamped 2021-11-13T18:16:01+00:00
, and also explains that rmdir(/var/www/html/data/attie/uploads/f33f7f89afc28b2042f894644325a408): Directory not empty
message... perhaps the directory is indeed not empty - it's still got this thread working in it.
So:
rmdir()
failing shouldn't be a hard error, and we need to understand why it's causing these knock-on issues (in particular the 0-byte final/target file)PUT
operations are writing to a temporary file (e.g: .tmp.2Ci3Q2cZv6
) before moving into place (i.e: 0000000010240000-0000000020479999
) - this ensures that we don't get partial content written over the top of complete contentMKCOL
that is verified on MOVE
)Ok, it's happened again.
MKCOL
, PROPFIND
- succeedsPUT
- connection breaks, phone knows, server does notPUT
- phone retries and succeedsMOVE
- fails (directory not empty - first PUT
still in progress)I'm starting to wonder if this is an artifact of (or perhaps exacerbated by) my setup, NFS and its handles (e.g: .nfs*
).
I suspect that when Nextcloud attempts the second / retry PUT
, it will delete the old / partial / stuck file first...
Consider:
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# cat > test &
[1] 58
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test#
[1]+ Stopped cat > test
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# ls -la
total 2
drwxr-xr-x 2 root root 3 Nov 22 14:08 .
drwxr-xr-x 4 www-data www-data 4 Nov 22 14:03 ..
-rw-r--r-- 1 root root 0 Nov 22 14:08 test
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# rm test
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# ls -la
total 2
drwxr-xr-x 2 root root 3 Nov 22 14:08 .
drwxr-xr-x 4 www-data www-data 4 Nov 22 14:03 ..
-rw-r--r-- 1 root root 0 Nov 22 14:08 .nfs000000000001ab1000000888
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# kill %1
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test#
[1]+ Terminated cat > test
root@ad66582ab5dc:/var/www/html/data/attie/uploads/test# ls -la
total 1
drwxr-xr-x 2 root root 2 Nov 22 14:08 .
drwxr-xr-x 4 www-data www-data 4 Nov 22 14:03 ..
@attie thats quite interestin, because this could possibly explain another problem, I have. The Android App keeps spamming me with conflict-messages for pictures, that look exactly the same. I think, this often happens during network-changes.
I think, this often happens during network-changes.
@bruennlein - that might make a lot of sense!
I'll keep digging when the issue presents, but I'm not quite settled what route to take, or how to approach the Nextcloud codebase yet... (any input from maintainers would be much appreciated!)
Hi,
Had to some degree the same issue as you guys.
Ran a sudo -u www-data php -d memory_limit=-1 -f /var/www/html/occ encryption:decrypt-all
, which resolved my upload issue.
Before running the command above, I checked whether I had any encryption modules, which I assumed I did not have as the GUI was saying so. I checked the encryption modules with sudo -u www-data php -d memory_limit=-1 -f /var/www/html/occ encryption:list-modules
, which returned nothing.
However, when I did sudo -u www-data php -d memory_limit=-1 -f /var/www/html/occ encryption:status
, encryption was enabled, but if I connected to my container and browsed to my files, all files were visible.
And to anyone else who as me has tried to find the nextcloud log on docker, please check: /var/www/html/data/
in your container volume.
So, do you guys, @attie / @bruennlein, have encryption enabled?
@zakria03 I don't have encryption enabled. So it's probably not related to encryption.
Sorry to bump this up but currently having the same issue. Just the android client refuses to work, tried anything I could but it won't budge.
Also no encryption enabled. Not sure how to work this out now.
@nssatlantis - please could you check in the nextcloud .../data/${username}/uploads/
folder? (e.g: if you're using the docker image: /var/www/html/data/${username}/uploads/
.
Please could you share details of your setup? e.g:
"fopen(/var/www/html/data/attie/uploads/f3412c2a7b72dc1d34716093dd216f63/0000000000000000-0000000004255266): failed to open stream: No such file or directory ...
/var/www/html/data/attie/uploads/f3412c2a7b72dc1d34716093dd216f63/
/var/www/html/data/attie/uploads/f3412c2a7b72dc1d34716093dd216f63/0000000000000000-0000000004255266
@zakria03 - I don't have encryption enabled either.
I haven't checked the logs, as I honestly just needed it to work right then and there.
If any one has this issue on Android what worked for me was to delete the account within the app, and to log back in again. Server no longer in maintenance according to the app and all works flawlessly again.
I uploaded 35 pictures using Android 3.19.0, 34 were successful, and one upload indicated that the server was in maintenance mode It can't upload anyway Uploaded successfully after changing the file name Not sure what the problem is?
I'm getting this error now too on the android app 3.19.1 ([Nextcloud Hub II] (23.0.3)) after auto upload tries to upload a couple videos.
It may also be triggered by editing and re-saving images with the same filename (in Google photos).
Anyway I currently have 43 notifications for a file that's stuck and (unfortunately) can't swipe them all away at once.
Hey anyone! I opened an extensive report here: https://github.com/nextcloud/android/issues/10805 If some of you are still experiencing the same issue, can you check and see if your problem is consistent with mine? Thanks! :v:
Also, are we all using NFS as our storage layer?
@skjnldsv - my current understanding is as outlined above, see: https://github.com/nextcloud/server/issues/23552#issuecomment-968187690 and https://github.com/nextcloud/server/issues/23552#issuecomment-975569937
In brief here:
MOVE
operation due to "in progress" first try in step 2I think there are two main points from what I can see:
Also, are we all using NFS as our storage layer?
Yes, I'm using NFS, and hypothesised about the .nfs*
files above too.
Considering I can reproduce the same issue with the web UI, it's not a connection issue :)
@skjnldsv
Also, are we all using NFS as our storage layer?
I'm using an external storage via SMB, I have the same problem.
Mounted at OS level? @jklmnn
No, using the External Storage app.
Hi, please update to 24.0.8 or better 25.0.2 and report back if it fixes the issue. Thank you!
Actual behaviour Android app refuses to auto-upload pictures and videos and says the server is in maintenance-mode. Same behavior, when trying to upload manually from the app. Uploading via browser works from the same device. Tried to turn maintenance-mode on and off again, no effect. For some reason, 6 photos of about 6-8MB and two videos with about 330MB went through. But the most files are stuck. Using the retry-button from inside the app (menu->uploads) has no effect.
Steps to reproduce Enable auto-upload and take some photos and videos
Environment data Android version: 9
Device model: Nokia 8
Stock or customized system: Stock
Nextcloud app version: 3.6.0 and 3.6.1
Nextcloud server version: 15.0.7