Closed hecsa closed 9 years ago
The files appear to be on the server, but considering I have some GBs, a new sync will take almost a week, with me not having all the files I own.
You mean the files are deleted locally but are all still on the server? Or some files also deleted from the server? Is there anything special about those files (special characters in file names? file in shared folder? external storage?) In general we'd need more information to be able to conclude on what could have happened..
Also, is it single files inside folders? Or complete folders with content?
In general we'd need more information to be able to conclude on what could have happened.
For this it could be useful that you're filling out the issue template provided here:
https://raw.githubusercontent.com/owncloud/client/master/issue_template.md
as asked in the "guidelines for contributing" (Shown in the box when creating a new issue).
Hi! @guruz No special files, just .doc, .xls, .ppt, or .pdf files. We have two Windows XP machines, both sync'ing same files. No special characters, I mean there is no rule for that...some files have some "á", some not. @RealRancor Tomorrow I'll get all this information, and paste the files/complete everything to have it properly documented. Thanks a lot for your time and attention!
HeCSa.
@RealRancor Here is the report:
Files should be in sync between both Windows XP PCs. Both must have same files on same paths, as configured.
Files get deleted in both computers, then downloaded, then deleted, then downloaded, etc. The downloaded files have changed their creation date to the download date. All files are messed with this issue. On both PCs.
Operating system: Ubuntu 13.10.
Web server: Apache root@WSPR01:~# /usr/sbin/apache2 -version Server version: Apache/2.4.6 (Ubuntu) Server built: Dec 5 2013 18:33:15
Database: Server version: 5.5.35-0ubuntu0.13.10.1 (Ubuntu)
PHP version: root@WSPR01:~# php --version PHP 5.5.3-1ubuntu2.1 (cli) (built: Dec 12 2013 04:22:11) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.5.0, Copyright (c) 1998-2013 Zend Technologies with Zend OPcache v7.0.3-dev, Copyright (c) 1999-2013, by Zend Technologies
ownCloud version: 6.0.7
Storage backend: Normal ext4 filesystem.
Client version: 1.8
Operating system: Windows XP.
OS language: Spanish
Installation path of client: C:\Archivos de Programa\owncloud
Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.
Template for output < 10 lines
owncloud --logwindow
or owncloud --logfile log.txt
(On Windows using cmd.exe
, you might need to first cd
into the ownCloud directory)
(See also http://doc.owncloud.org/desktop/1.8/troubleshooting.html#client-logfile )https://gist.github.com/hecsa/b67d5da3b676ee10138e
https://gist.github.com/hecsa/11fac238616f00120d42
Contains logs for 108 users, rmurmis is mine, and I received messages from mtoloza having the same issue: https://gist.github.com/hecsa/90f94fcd7c79376a4c43
Thanks a lot!
@hecsa Can you check your webserver's access.log
for DELETE
entries for the files you are missing?
CC @dragotin
@guruz @dragotin Hi! Here is the details for this file:
root@WSPR01:/var/log/apache2# grep DELETE access.log.1 | grep rmurmis 192.168.0.132 - rmurmis@estabe.com.ar [06/Apr/2015:12:06:19 -0300] "DELETE /cloud/remote.php/webdav/ARCH/TAX-/VARI/Acceso%20directo%20(3)%20a%20Biblio.xlsx.lnk HTTP/1.1" 204 724 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - rmurmis@estabe.com.ar [06/Apr/2015:12:06:04 -0300] "DELETE /cloud/remote.php/webdav/ARCH/TAX-/VARI/Acceso%20directo%20(2)%20a%20Biblio.xlsx.lnk HTTP/1.1" 204 725 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" root@WSPR01:/var/log/apache2# zcat access.log.2.gz | grep DELETE | grep rmurmis 192.168.0.132 - rmurmis@estabe.com.ar [31/Mar/2015:19:19:05 -0300] "DELETE /cloud/remote.php/webdav/ARCH/RDM-/TAX/GANA/2014/Asiento%20de%20cierre%20de%20resultados.xls HTTP/1.1" 204 725 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - rmurmis@estabe.com.ar [31/Mar/2015:19:19:11 -0300] "DELETE /cloud/remote.php/webdav/ARCH/RDM-/TAX/GANA/2014/Asiento%20de%20cierre%20patrimonial.xls HTTP/1.1" 204 725 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - rmurmis@estabe.com.ar [01/Apr/2015:15:25:40 -0300] "DELETE /cloud/remote.php/webdav/ARCH/RDM-/VARI/rmurmis.wab HTTP/1.1" 204 725 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" root@WSPR01:/var/log/apache2#
There is no file in access.log with DELETE in its command line. And those lines do not reflect the reality of the deletion for user rmurmis. If I filter with "mtoloza" (the other user experiencing problems) this is worst, and maybe more representative:
root@WSPR01:/var/log/apache2# zcat access.log.2.gz | grep DELETE | grep mtoloza | wc -l 2 root@WSPR01:/var/log/apache2# grep DELETE access.log.1 | grep DELETE | grep mtoloza | wc -l 1095 root@WSPR01:/var/log/apache2# grep DELETE access.log | grep DELETE | grep mtoloza | wc -l 0 root@WSPR01:/var/log/apache2#
Something interesting I noticed is that MySQL is eating a lot of CPU...consider that this server is configured with 4 CPUs:
root@WSPR01:/var/log/apache2# top top - 11:55:50 up 3 days, 12:58, 2 users, load average: 8.18, 8.39, 8.20 Tasks: 142 total, 1 running, 141 sleeping, 0 stopped, 0 zombie %Cpu(s): 69.9 us, 6.7 sy, 0.0 ni, 20.6 id, 0.0 wa, 0.0 hi, 2.8 si, 0.0 st KiB Mem: 2064352 total, 1897456 used, 166896 free, 121936 buffers KiB Swap: 3906556 total, 22816 used, 3883740 free, 1404312 cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 993 mysql 20 0 350m 171m 4056 S 259.7 8.5 4872:58 mysqld 8196 www-data 20 0 179m 17m 9968 S 20.0 0.9 1:56.45 apache2 11681 www-data 20 0 179m 17m 9.8m S 7.0 0.9 1:05.44 apache2 2204 www-data 20 0 179m 16m 8988 S 6.7 0.8 3:28.08 apache2 12237 www-data 20 0 178m 16m 9.8m S 6.7 0.8 0:52.27 apache2 ...
Thanks a lot! HeCSa.
@hecsa Thanks
And those lines do not reflect the reality of the deletion for user rmurmis.
Do you mean those lines are not the files you were missing? So the client didn't send any DELETE for those to the server? (Same for mtoloza?)
Yes, what we basically want to know is if there have been DELETE requests from any client in the interesting timeframe for the files that were unexpectedly deleted.
@dragotin Exactly! This is the effect we are experiencing! Thanks, and best regards,
HeCSa.
@hecsa Could you grep if any PROPFIND
did not return a HTTP 207 or otherwise failed?
@guruz Hi! Tons of "401 992" and "401 993" when I grep: My command was: root@WSPR01:/var/log/apache2# grep PROPFIND access.log | grep -v 207 | more The results are: 192.168.0.132 - - [12/Apr/2015:06:40:00 -0300] "PROPFIND /cloud/remote.php/webdav/photos HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:01 -0300] "PROPFIND /cloud/remote.php/webdav/music HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:01 -0300] "PROPFIND /cloud/remote.php/webdav/videos HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:29 -0300] "PROPFIND /cloud/remote.php/webdav/documentos HTTP/1.1" 401 993 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:29 -0300] "PROPFIND /cloud/remote.php/webdav/videos HTTP/1.1" 401 993 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:30 -0300] "PROPFIND /cloud/remote.php/webdav/Desktop HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:30 -0300] "PROPFIND /cloud/remote.php/webdav/musica HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - - [12/Apr/2015:06:40:31 -0300] "PROPFIND /cloud/remote.php/webdav/photos HTTP/1.1" 401 992 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1"
192.168.0.132 is the machine that contains the httpd server that redirects to the ownCloud server via some lines in the httpd.conf file:
ProxyPass /cloud http://192.168.0.8/cloud ProxyPassReverse /cloud http://192.168.0.8/cloud
192.168.0.8 is the ownCloud server, and 192.168.0.132 is the redirector httpd server.
Thanks, and best regards,
HeCSa.
Did you switch back to 1.7.x version?
Is really 1.8.0 used (check the settings dialog of the client)?
(Because 1.8.0 should display different versions in log..)
@hecsa the PROPFINDs above show that the client is old, that is not 1.8.0. csyncoC/0.91.5 neon/0.30.1 is way older.
@guruz @dragotin Version is 1.8. We didn't switched back to 1.7. Maybe not all the clients were upgraded. Which csync and neon versions should I grep in the log files to check the 1.8 client behavior? Thanks again!
HeCSa.
@hecsa Can you add | grep -v ' 207 ' | grep -v ' 401 ' ? 401 is no real error :-) It would be interesting to see if the 1.8.0 client received a PROPFIND response that is not one of those..
@guruz Interesting! I see Internal Server Error here?
root@WSPR01:/var/log/apache2# grep PROPFIND access.log | grep -v 207 | grep -v 401 | more 192.168.0.132 - ncarral@estabe.com.ar [13/Apr/2015:12:29:47 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - starditti@estabe.com.ar [13/Apr/2015:12:29:45 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - lfranco@estabe.com.ar [13/Apr/2015:12:50:43 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0"
...and in the previous log file:
192.168.0.132 - arigueira@estabe.com.ar [07/Apr/2015:16:51:45 -0300] "PROPFIND /cloud/remote.php/webdav/videos HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.7.1 " 192.168.0.132 - - [07/Apr/2015:16:51:45 -0300] "PROPFIND /cloud/remote.php/webdav/documents HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) csyncoC/0.91.5 neon/0.30.1" 192.168.0.132 - rajalla@estabe.com.ar [07/Apr/2015:16:51:45 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - fhiga@estabe.com.ar [07/Apr/2015:16:52:13 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - degan@estabe.com.ar [07/Apr/2015:16:54:21 -0300] "PROPFIND /cloud/remote.php/webdav/music HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - mfuxman@estabe.com.ar [07/Apr/2015:16:51:45 -0300] "PROPFIND /cloud/remote.php/webdav/documents HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.7. 1" 192.168.0.132 - slarrotonda@estabe.com.ar [07/Apr/2015:16:51:45 -0300] "PROPFIND /cloud/remote.php/webdav/ HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - mtoloza@estabe.com.ar [07/Apr/2015:16:53:15 -0300] "PROPFIND /cloud/remote.php/webdav/Videos HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) mirall/1.8.0" 192.168.0.132 - fzanoni@estabe.com.ar [07/Apr/2015:16:53:03 -0300] "PROPFIND /cloud/remote.php/webdav/Documents HTTP/1.1" 500 220 "-" "Mozilla/5.0 (Windows) csyncoC/0.9 1.5 neon/0.30.0"
I stopped here with the logs because of "mtoloza", she is using 1.8.0. Is there any way I can diagnostic the "500" messages here with no impact to the normal operations? Thanks a lot!
HeCSa.
Looks like I have the same issue. To my horror I noticed that a lot of the files/folders on my computer covered by owncloud were all getting downloaded from the server as they seemed to have all gotten deleted locally. It's gigabytes of data, and for the last days I was anxiously waiting for them to be re-downloaded. Checking on the status today, they got deleted again and are now downloading again.
This is with the current 1.8.0 (build 4893) on Windows 7 client and server version 8.0.2.
I downgraded to 1.7.1. These two links should be helpful for people who need the same solution: https://download.owncloud.com/desktop/stable/ownCloud-1.7.1.4382-setup.exe https://doc.owncloud.org/desktop/1.8/autoupdate.html#preventing-automatic-updates-in-windows-environments
@thederan Can you also check the http access log on your server if you got any errors? https://github.com/owncloud/client/issues/3102#issuecomment-92421200 This would be important for us to see if there is a pattern in this bug.
We have a new nightly build which contains more sanity checking with regards to listing the directory on the server. You can also try that: http://download.owncloud.com/desktop/daily/ownCloud-1.8.0.4944-nightly20150414-setup.exe
If it does not re-download your files, you can exit the client, then delete the .csync_journal.db*
in sync directory, then re-start the client (preferably the nightly build)
@thederan Did you find the time to check my previous comment above?
"about 2000 files are deleted #3116" is the same. I have send you all my logfiles. 5000 files on my server 3000 on my computer Windows 7. Client is 1.8.0 (build 4893), Server is ownCloud 7. In the acces.log is no delete. It happened Tuesday night while I was sleeping (so not my fault). What I can see in the access.log is that the client started to downlod (GET) several fles and then stopped the connection after some hours. That is the actual state and because of an windows update I have to restart my computer, if it is ok for you
... and I am the only one who is syncing with my server. No other client
the nightly build client is now downloading all the files, but still having problems
16.04.2015 14:05:01PDF9783827328519_SWE.zip Arbeit Operation abgebrochen22 MiB 16.04.2015 14:05:01PDF9783827326515_SOA.zip Arbeit Operation abgebrochen25 MiB 16.04.2015 14:05:01New Project 20130115 1104.sql Arbeit Operation abgebrochen11 MiB 16.04.2015 14:05:01setup.exe Arbeit Operation abgebrochen456 KiB 16.04.2015 14:05:01Nominator.msi Arbeit Operation abgebrochen7,1 MiB 16.04.2015 14:05:01Nominator.msi Arbeit Operation abgebrochen7,1 MiB 16.04.2015 14:05:01Setup.exe Arbeit Verbindung beendet456 KiB
@hecsa @JensHH @thederan The missing files are still in the oc_filecache table on the server right?
Hi! I'm having good results with 1.7.1 client. I stopped to post here, because of the workload I had testing and changing the client to 1.7.1 (my plan is to change it in 108 machines!), and disabling the automatic upgrade capabilities. About oc_filecache, it seems that some of the files are there. Something I don't understand is, for example, this about that table:
+-------------+---------+------+----------------------------------+--------+------+----------+----------+---------+------------+---------------+-----------+------------------+---------------+ | max(fileid) | storage | path | path_hash | parent | name | mimetype | mimepart | size | mtime | storage_mtime | encrypted | unencrypted_size | etag | +-------------+---------+------+----------------------------------+--------+------+----------+----------+---------+------------+---------------+-----------+------------------+---------------+ | 2957451 | 1 | | d41d8cd98f00b204e9800998ecf8427e | -1 | | 2 | 1 | 6083643 | 1406167959 | 1391019471 | 0 | 0 | 53d06b972286a | +-------------+---------+------+----------------------------------+--------+------+----------+----------+---------+------------+---------------+-----------+------------------+---------------+
Why I'm having such a record there, with no legible filename? Other rows contains the filename, as stated in the filesystem... Thanks again!
You want me to look into my database? Ok ;-) Let's take the file PDF9783827326515_SOA.zip. It is on the server in the folder "Sicherung". In the database I find 3 entries. There is a difference in fileid, path, path_hash, parent and etag. Here are the values for path: files/Sicherung/PDF9783827328519_SWE.zip files_trashbin/files/Arbeit.d1411229783/PDF9783827328519_SWE.zip files_trashbin/files/Arbeit.sav.d1411743880/PDF9783827328519_SWE.zip
Interesting for me because I have never deleted or changed this file
@guruz I checked an access log for PROPFIND from the day before I downgraded. Excluding all 4xx codes there were maybe 10 or so 503 entries, nothing on the deleted files. The filecache table still has the files that were deleted on the client.
Meanwhile my nightly build client has downloaded some files but stopped again. The client log says e. g. 04-16 18:16:01:457 0x3ab440 OCC::SocketApi::command_RETRIEVE_FILE_STATUS: void OCC::SocketApi::command_RETRIEVE_FILE_STATUS(const QString&, QLocalSocket*) "C:\Arbeit\kalender.ods" 04-16 18:16:01:458 0x3ab440 OCC::SocketApi::fileStatus: OO File "C:\Arbeit/kalender.ods" is not existing 04-16 18:16:01:459 0x3ab440 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:ERROR:C:\Arbeit\kalender.ods"
The file "kalender.ods" is on the server and in the oC webinterface.
Because my client was just starting and stopping, and because 2000 files had to be downloaded from the server, I decided to delete 4 files.
I remember that my server provider told me, that these files might have a virus some months ago, what is not true. I'm not sure if he has deleted these files and oC client has uploaded them again or if he did something to hide these files. The rights for this files where rwxr-xr-x and the owner is the same like for all other files.
I deleted these 4 files on the server (and they are still in my backup). They were not on the client. Now the client is downloading files again.
I send you the client logfile via email which I made just before I deleted these files. Please have a look at line 7643 and following lines.
It seems that I got all my files back
@thederan @JensHH if this ever comes back..
Can you please try to use something like:
curl -X PROPFIND https://user:pwd@cloud.example.com/remote.php/webdav/your/path/where/there/is/files/which/dont/show/up/on/client |tidy -xml -i
(tidy part us optional)
to see if the server returns the files which are missing on your desktop? This will give you a raw format which is used by the client to see which files are onthe server.
If you afterwards close your client, delete .csync_journal.db*
and then start client again, will the files come back?
Can you also try to use beta1
from now on? We have some fixes in there which could help. https://owncloud.org/install/#testing-development
@hecsa So you also got your files back? if not can you please check the comment I made above with regards to the PROPFIND
output?
@hecsa Or instead of the PROPFIND
maybe better to create a file on client or server in that specific directory and then see if the other files come back..
@rhabbachi Can you copy/paste your comment to here: https://github.com/owncloud/client/issues/3131 and delete the one here? (or create a new one)
This issue is for the bug where files STAY on the server and are only deleted locally.
CC @PVince81 FYI shared-folder thingy.
Hi @guruz , I think I finally understand the full nature of the problem. If we installed OC client in a machine, and that machine automatically updated the client, and (here is what is interesting) that machine work in a network different than the one used when installing the client, it fails. Nothing happens if the machine continues to work on the same network. Then, if an ethernet cable was in place when installing the client, and the user goes to a place where wifi is used, outside of our office, it fails. Something more interesting (and horrifying) is that the client absolutely overrides the ignored extension list, and deletes everything. For example, some of our users have no .pst files anymore because OC deleted them. Now you can imagine why I'm taking one or more days to answer here...I'm starting to be a friend of GetDataBack, because OC instead of backing up the machines, is destroying everything it has in front of it...this is my 3rd day without sleeping just to recover deleted files...a nightmare on Elm street...
Sorry @guruz ... another thing...no PROPFIND entries when deleting the .pst files, and no way to recover them from the OC server, because those .pst files were on the ignored extension list. Double nightmare...the information is no longer there, and I have no place in OC to look for it...so the title of this issue can avoid having the "(while still being on server)", because those files aren't, and were never sync'ed. Thanks, and best regards.
Hi @hecsa ,
I think this problem exists only in 1.8 client. I downgraded to 1.7.1. And I will downgrade all my users to 1.7.1 and will disable auto update (changing the serveur config.php and adding this 'updatechecker' => false,)
For me the problem exists since March 20th and the 1.8 was released on 17th...
@hecsa Thanks. your comment made me to check the code again and try to reproduce the behaviour like when someone is behind a captive portal in a WiFi network. I fixed another bug which was triggering those empty client directories.
Fix will be in 1.8.1
@guruz Hi! Excellent! I'll do all the test in a controlled environment when 1.8.1 arrives. Thanks a lot!
HeCSa.
https://owncloud.org/install/#testing The rc2 has code to automatically bring back the files. Sorry for the trouble. If this still happens please re-open and comment.
@sleepysmurf The best way is to install 1.8.1rc2(see URL two commits up) or 1.8.1(coming out tomorrow). It will bring the files back (they should be still on the server, nothing locally)
do we know what caused the problem in 1.8.0 ?
@sleepysmurf Yes, otherwise we would not claim that it was fixed in 1.8.1 :-)
oh.. I was probing for more details on the problem (I am curious)
I guessed as much :) See #3102 for the gory details.
Hi all,
I'm experiencing a similar issue (see #6282) after Ubuntu client update toVersion 2.4.0 (build 8911)
.
Files are not present anymore locally but are still on the server !
Is there a way to downgrade owncloud client version on ubuntu ? I would be (very) happy to get back my files. Thanks !
Hi! I'm using owncloud for some time, almost half a year. Everything were ok until last week, when something was upgraded from the client side, and then the files started to be deleted. The files appear to be on the server, but considering I have some GBs, a new sync will take almost a week, with me not having all the files I own. Please, let me know if there is something I need to check to avoid this behavior, and to have all my files again in my folders. The server is 6.0.7, and the client is 1.8, I'm using Windows XP in my machine, planing to migrate to Windows 8 in the near future...if I can recover all my files again! Thanks in advance, and best regards,
HeCSa.