Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Office 365 files stored in a vault won't open when I'm offline #527

Closed
An-error-occurred opened this issue Jun 28, 2017 · 16 comments
Closed
Labels
mount:webdav os:windows state:awaiting-response We need further input from the issue author state:has-workaround There is a known workaround for the described problem type:upstream-bug Something isn't working in upstream

Comments

@An-error-occurred
Copy link

An-error-occurred commented Jun 28, 2017

This is a bug report.

I'm using Windows in version: Win10 Pro 1703; Build 15063.413

I'm running Cryptomator in version: 1.3.0-RC8

Description

OFFICE FILES DO NOT OPEN WHEN I'M NOT ONLINE
Pictures will load and if I copy the office file (Word or Excel) to another folder outside the vault, I can read and edit the files. The error reads: "[Pfad] konnte leider nicht geöffnet werden". It both concerns my Surface and my desktop PC (identical Win version and Office).

This is a major issue, since I cannot be online all the time with my portable device.

Workaround
This issue is not directly caused by Cryptomator but is a sideeffect of Office and the Office Upload Center not working correctly.

One workaround for this issue is to copy the files in question to another directory outside of the vault (e.g. the Desktop), work with the files from there and copy back to the vault afterwards.

Another workaround is to use the subst command on the virtual drive. So if the encrypted drive is drive F: you may run subst G: F:. When using drive G: afterwards you will not recieve this warnings.

@overheadhunter overheadhunter added state:has-workaround There is a known workaround for the described problem type:upstream-bug Something isn't working in upstream labels Jun 28, 2017
@An-error-occurred
Copy link
Author

Additional info:

I disabled the Office Synchronisation in Onedrive (Office Upload Centre): OneDrive Properties -> Office -> Office-Dateien, die ich öffne, mit Office 2016 synchronisieren.
In principal, it didn't change anything. However, I could open two documents and they now stated that they are offline copies from a server version that might be newer. Which doesn't phase me at all, but I had access at least!
I don't know why only these two files could be opened inside the vault and I can't say if it has st to do with the Upload Centre. The rest still does not open.

@An-error-occurred
Copy link
Author

Hey guys,
the problem persists and I would very much appreciate a fix. As a teacher responsible for data security, I am going to suggest using Cryptomator in our school and I am preparing a presentation on handling sensitive data in the classroom. If I advise my colleagues to follow my example, it would be great if this bug could be eradicated, because as you cannot be online in every room, you sometimes need to open Office files offline from the vault, which doesn't work yet.
Any thoughts on that?

@markuskreusch
Copy link
Contributor

@An-error-occurred

I guess the problem here is, that the Office Upload Centre does some "magic" stuff when opening office files from Cryptomator and because some errors and bugs exist in the Upload Centre itself office tells you the weird stuff about that the path could not be opened or would be an offline copy.

You told us, that it is possible to copy the file out of Cryptomator and open it from your desktop. This prooves that access to the file is possible (because if a file could not be read it could not be copied to another location). Thus it is not really a problem of Cryptomator providing the files the wrong way but more a problem of Office trying to do the wrong stuff to read the file.

For now our possibilites to fix this from within Cryptomator are limited. We can not change the way office tries to access the files. The workaround suggested by you - copying the file to the desktop, edit it there, and copying it back to the vault is currently the way to go.

The only way to really fix this is to wait for Microsoft to improve how Office handles files from so called WebDAV shares (this is how Cryptomator provides the virtual drive). Nevertheless we are working on an improvement of our filesystem interface (especially to increase performance) and will provide a dokany implementation ( #207, no date scheduled yet). This should as a side effect also solve this issue.

@An-error-occurred
Copy link
Author

I see your point and although it does look like Office is at fault, it doesn't change the fact that working straight out of a vault doesn't work with Cryptomator and the workaround is a bit of a hassle...
I'll try and kill this upload centre... and keep waiting for the update. Thanks for getting back in touch.

@An-error-occurred
Copy link
Author

An-error-occurred commented Sep 12, 2017

All right, maybe this helps you: After some testing, I could effectively disable / kill the dreadful Upload Center using this hint and my Comodo Firewall: https://answers.microsoft.com/en-us/office/forum/office_2016-officeapps/office-2016-upload-center-how-do-i-get-rid-of-it/e471b430-d940-4b6c-88ec-af0336cd3e93?auth=1

Now it does not start anymore when I try to open or save an Office Document. However, the error still pops up.

@markuskreusch
Copy link
Contributor

I understand what you did and if it worked this way disabling Upload Center would be the way to go. Obviously Office does not actually not need the Upload Center to behave broken. As before, the fact that access to the files is possible when copying it out of the vault means that access to the file in Cryptomator is possible. Office must just not be doing it right.

To make this clear: We are not happy with the situation and although we believe that this problem is actually caused by Office we of course want it to be solved. Currently we do not have any options to solve it because we do not understand what acutally goes wrong. If we have a way to fix this in a reasonable way and with reasonable effort we will do so.

I tried to reproduce the problem today and analyze it further but did not succeed. Maybe we will succeed if we have more information about the exact steps. The following could help us:

  • Which exact version of office did you use?
  • How did you go offline? Did you disconnect the cable, did you switch your network interface off in the system settings or did you do something else?
  • Do you have any antivirus / firewall software running? You may disable it temporarily to see if that impacts the process.

Just a question before I dig further into it: In your report (but its 6 weeks old now) you mentioned you are using 1.3.0-RC8. Did you update Cryptomator to the latest version yet and do you still have problems?

@An-error-occurred
Copy link
Author

Thank you for your trouble. To answer your questions:

  1. I'm currently using 1.3.1 on both my PC and Surface (auto-update is enabled).
  2. I use the most up-to-date version of Office 365 on both devices.
  3. By "offline" I mean when there's no available WiFi-network or when I disconnect from my home WiFi. The same result if I disable the WiFi-device altogether.
  4. There's the Windows Firewall and Comodo active on my PC but there's only the Windows Firewall on my Surface. Even if I disable both, there is no change in behaviour. BUT:

Interestingly enough, the documents that I could not open and I then copied to the Desktop and - after working with them - back into my vault, DO open. MS word says: "Dies ist eine Offlinekopie des Serverdokuments, die am 12.09.2017 um 12:20 Uhr aktuell war." Word files I have not copied and used to replace the original file in the vault still give out the error.

@markuskreusch markuskreusch changed the title Office files stored in a vault won't open when I'm offline Office 365 files stored in a vault won't open when I'm offline Sep 13, 2017
@markuskreusch
Copy link
Contributor

@An-error-occurred
Thanks for the details. One additional question regarding the office version you are using: Which variant of Office 365 do you use? This must not, but maybe relevant. As mentioned I could not reproduce this using a regular install of Office 2016 so maybe this only happens when using Office 365.

@An-error-occurred
Copy link
Author

Hey there,
it's Office 365 Home. I tried it when logged in with my MS Account and when not logged in. No difference.

@rmti
Copy link

rmti commented Sep 19, 2017

Hello,
Thought I would share something re: this. I did a subst command to link a different drive to the Cryptomator drive and I did not get the error when working offline. For example, if F: is the Cryptomator drive, I run "subst G: F:" and I receive the error opening an excel file from F: but not if I open the same (or a different spreadsheet) from G:

Hope this helps...

@overheadhunter
Copy link
Member

@rmti haha great workaround :D Sometimes Windows is simply insane. Thanks for sharing!

@An-error-occurred
Copy link
Author

Here's more info that might prove helpful:

If there's no WiFi-connection: Problem as described in great detail.
If there's faulty WiFi-connection, meaning: the PC can access the router but NOT the internet, the problem is apparently gone! I found out by accident, as my provider had scheduled some maintenance and I was offline but WiFi was on -> I could open all files.

@stale
Copy link

stale bot commented Jun 17, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the state:stale Issues without any activity that will be closed automatically label Jun 17, 2018
@An-error-occurred
Copy link
Author

bump
It's still an issue.

@stale stale bot removed the state:stale Issues without any activity that will be closed automatically label Jun 18, 2018
@overheadhunter
Copy link
Member

Good news, everyone! We've released version 1.4.0-beta2, which introduces Dokany support. You now have the choice between Dokany and WebDAV based virtual hard drives.

Please retest this issue with Dokany enabled.

@overheadhunter overheadhunter added the state:awaiting-response We need further input from the issue author label Jul 12, 2018
@no-response no-response bot closed this as completed Jul 26, 2018
@no-response
Copy link

no-response bot commented Jul 26, 2018

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
mount:webdav os:windows state:awaiting-response We need further input from the issue author state:has-workaround There is a known workaround for the described problem type:upstream-bug Something isn't working in upstream
Projects
None yet
Development

No branches or pull requests

5 participants