search

owncloud / client

🖥️ Desktop Syncing Client for ownCloud
GNU General Public License v2.0
1.4k stars 667 forks source link

Windows client: Error updating metadata: WindowsError: ffffffff80070005: Access is denied #10382

Closed helgeklein closed 1 year ago

helgeklein commented 1 year ago

Pre-submission Checks

Describe the bug

The Windows desktop client 3.0.0.9215 with virtual files enabled starts synchronizing, then stops with the error Error updating metadata: WindowsError: ffffffff80070005: Access is denied.

Analysis

ownCloud client log

For every file to be synced, the log of the ownCloud client contains two lines like the following:

23-01-01 22:50:16:049 [ debug sync.statustracker ]  [ OCC::SyncFileStatusTracker::slotAboutToPropagate ]:   Investigating "Some folder/Some image.JPG" OCC::SyncFileItem::NoStatus SyncInstruction(CSYNC_INSTRUCTION_NEW)
23-01-01 22:50:16:049 [ warning sync.vfs.win ]: void __cdecl OCC::VfsWin::fileStatusChanged(const class QString &,class OCC::SyncFileStatus) : could not make handle for "D:/Bilder/Album/Some folder/Some image.JPG" "WindowsError: ffffffff80070005: Access is denied."
File system permissions

I checked the permissions on the files and folders, of course. They have the default permissions inherited from my D: drive. Since I am not running ownCloud as admin, the resulting permissions are modify (not full control).

Process Monitor trace

I traced the file system operations with Microsoft Sysinternals Process Monitor. This shows that ownCloud tries to open each file with the following desired access:

Root Cause

It seems the issue is caused by ownCloud trying to open the files to be synchronized with Write DAC access, which is the right to change permissions.

Standard (=non-admins) users by default don't have the right to change permissions on files/folders. That would require full control permissions, but standard users only have modify.

Workaround

I disabled virtual file support in the options of the sync connection and the error was gone.

Expected behavior

I expect ownCloud to work correctly with the default file system permissions of non-admin users. Specifically, I expect ownCloud not to try to open files with Write DAC (change permissions) access.

Steps to reproduce the issue

  1. Create a space in ownCloud web.
  2. Install Windows desktop client 3.0.0.9215.
  3. Add the space you created in the Windows client and select a local folder with existing data (images, in my case).
  4. Synchronize the space.

Screenshots

image

image

Logs

23-01-01 22:50:16:049 [ debug sync.statustracker ] [ OCC::SyncFileStatusTracker::slotAboutToPropagate ]: Investigating "Some folder/Some image.JPG" OCC::SyncFileItem::NoStatus SyncInstruction(CSYNC_INSTRUCTION_NEW) 23-01-01 22:50:16:049 [ warning sync.vfs.win ]: void __cdecl OCC::VfsWin::fileStatusChanged(const class QString &,class OCC::SyncFileStatus) : could not make handle for "D:/Bilder/Album/Some folder/Some image.JPG" "WindowsError: ffffffff80070005: Access is denied."

Client version number

Windows desktop client 3.0.0.9215

Desktop environment (Linux only)

No response

Client package version and origin (Linux only)

No response

Installation path (Windows only)

c:\Program Files\ownCloud

Server information

Dockerized ownCloud Infinite Scale.

# docker exec owncloud ocis version
Version: 2.0.0+244374459
Compiled: 2023-01-01 00:00:00 +0000 UTC

Additional context

No response

TheOneRing commented 1 year ago

Hi @helgeklein . I'd expect that user A has full access on files created by user A. Did you recently reinstall Windows and the files in D:\Daten are from a previous install, in that case you might need to re add the permissions for your user as the internal user id might have changed.

helgeklein commented 1 year ago

Hi Hannah (@TheOneRing),

when you format an NTFS partition, Windows sets the following default permissions:

As you can see, non-admin users never have full control (except for their user profile directory %USERPROFILE%), and that's the way it should be.

ownCloud shouldn't need Write DAC permissions - why should it change permissions on the files it's synchronizing?

BTW, other sync products I've used don't need Write DAC either, they work perfectly fine with the default Modify permissions. This includes Google Drive, Tresorit, and Egnyte.

TheOneRing commented 1 year ago

As far as I can remember we need Write DAC to convert files to placeholders (virtual files).

I created a vm, added a test user without admin permissions, I attached a ntfs drive. I log in with the test user and create a sync on the new drive. File sync as expected no errors occur.

If I however copy some files from User A to the new drive and then try to upload them as User B, using ownCloud, I get the same error as you.

helgeklein commented 1 year ago

Hi Hannah, thanks for taking the time to investigate this issue.

It would be nice if you could verify if Write DAC is indeed required when converting physical to virtual files (placeholders).

Independent of that, it might be a good idea to improve the user experience as follows:

As a user, when I point an ownCloud space at a directory with data in it, I wouldn't expect the data to be converted to virtual files/folders. I'd simply expect them to stay where they are and be synchronized.

If, on the other hand, I point a space at an empty directory, I, as a user, might be happy with instantly having the space in my local filesystem by way of virtual files.

What I mean by that is that in case A (existing files), it might be a good idea not to enable virtual files by default.

Compare this to the mount command: I can only mount a filesystem into an empty directory (case B).

jnweiger commented 1 year ago

@helgeklein I fully agree with your expected user experience.

But that is exactly what I already experience with desktop client 3.0.0.9215- on Windows 11 with default settings.

grafik

While this enables virtual file support for my non-empty folder SyncMe, it keeps the data locally. It only gives us the option to later choose sync behaviour "Always keep on this device" or "Free up space" (for the entire space, or for folders or files individually)

For me, enabling virtual files support, does not replace everything with placeholders. Did that happen to you? I believe write DAC should not be needed for the initial sync run. Did you manually choose the sync behaviour?

TheOneRing commented 1 year ago

@helgeklein I fully agree with your expected user experience.

* locally existing files should remain "Available on this device"

* new files coming in from the server should be added as "Available when online"

But that is exactly what I already experience with desktop client 3.0.0.9215- on Windows 11 with default settings.

grafik

While this enables virtual file support for my non-empty folder SyncMe, it keeps the data locally. It only gives us the option to later choose sync behaviour "Always keep on this device" or "Free up space" (for the entire space, or for folders or files individually)

For me, enabling virtual files support, does not replace everything with placeholders. Did that happen to you? I believe write DAC should not be needed for the initial sync run. Did you manually choose the sync behaviour?

The files remain on the disk but they are converted to locally available placeholders. This is requires to enable the virtual files behavior like status icons and the free up local space or always keep on this device context menu actions .

jnweiger commented 1 year ago

Aah! :bulb:

"locally available placeholder" sounds like a self-contradiction to me. Okay, need to adjust my mental model now...

TheOneRing commented 1 year ago

We will add documentation that file ownership is required. https://github.com/owncloud/docs-client-desktop/issues/347