Recipient cannot access shared files

[HanaGemela]

Windows 10
Client: 2.6.0daily20190820 (build 12286)
Server: 10.3.0 alpha, 10.2

Steps to recreate:

1. User A shares folder Test with user B, granting edit-create + edit-delete permissions.
2. User A creates folders Test/Sub, Test/testfolder and file Test/file.txt
3. User B is connected with a desktop client, folder Test is synced.

Actual result: Access to files denied
Expected result: Files are accessible

[ckamm]

Probably relates to owncloud/core#35884

[ckamm]

@HanaGemela Do you have a log file? Particularly the lines around "Received sharing permissions for" when user A shares the folder initially are interesting.

The client is intended to discover the maximum possible permissions for sharing of an item and then create a user share with that. See ShareDialog::slotPropfindReceived for maximum sharing permissions retrieval.

[ckamm]

I can't reproduce the problem. Spoke to @HanaGemela, she'll also try to reproduce and save logs.

[HanaGemela]

I cannot recreate either. The below is the error for the file not synced yesterday

08-22 15:44:27:380 [ info gui.application ]:	Sync state changed for folder  "http://10.42.16.185:8080/remote.php/dav/files/carol/" :  "Sync Running"
08-22 15:44:27:380 [ info sync.propagator ]:	Starting INSTRUCTION_NEW propagation of "Test4/file.txt.txt" by OCC::PropagateDownloadFile(0x8e82ee0)
08-22 15:44:27:380 [ debug sync.propagator.download ]	[ OCC::PropagateDownloadFile::start ]:	"Test4/file.txt.txt" 0
08-22 15:44:27:380 [ debug sync.propagator ]	[ OCC::OwncloudPropagator::localFileNameClash ]:	CaseClashCheck for  "C:/Users/Hana Gemela/ownCloud17/Test4/file.txt.txt"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 QVariant(QString, "Test4/file.txt.txt")
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT tmpfile, etag, errorcount FROM downloadinfo WHERE path=?1"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 QVariant(QString, "Test4/file.txt.txt")
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT lastTryEtag, lastTryModtime, retrycount, errorstring, lastTryTime, ignoreDuration, renameTarget, errorCategory, requestId FROM blacklist WHERE path=?1 COLLATE NOCASE"
08-22 15:44:27:394 [ warning sync.propagator ]:	Could not complete propagation of "Test4/file.txt.txt" by OCC::PropagateDownloadFile(0x8e82ee0) with status OCC::SyncFileItem::NormalError and error: "Access is denied."
08-22 15:44:27:394 [ debug sync.statustracker ]	[ OCC::SyncFileStatusTracker::slotItemCompleted ]:	Item completed "Test4/file.txt.txt" OCC::SyncFileItem::NormalError 8
08-22 15:44:27:394 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:SYNC:C:\\Users\\Hana Gemela\\ownCloud17" to QLocalSocket(0x88dde68)
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 QVariant(qlonglong, -8004181106820949646)
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::bindValue ]:	SQL bind 1 QVariant(qlonglong, -8004181106820949646)
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT path, inode, modtime, type, md5, fileid, remotePerm, filesize,  ignoredChildrenRemote, contentchecksumtype.name || ':' || contentChecksum FROM metadata  LEFT JOIN checksumtype as contentchecksumtype ON metadata.contentChecksumTypeId == contentchecksumtype.id WHERE phash=?1"
08-22 15:44:27:394 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:IGNORE:C:\\Users\\Hana Gemela\\ownCloud17" to QLocalSocket(0x88dde68)
08-22 15:44:27:394 [ debug sync.localdiscoverytracker ]	[ OCC::LocalDiscoveryTracker::slotItemCompleted ]:	inserted error item "Test4/file.txt.txt"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "SELECT path FROM conflicts"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	SQL exec "DELETE FROM flags WHERE path != '' AND path NOT IN (SELECT path from metadata);"
08-22 15:44:27:394 [ debug sync.database.sql ]	[ OCC::SqlQuery::exec ]:	Last exec affected 0 rows.
08-22 15:44:27:394 [ debug sync.database ]	[ OCC::SyncJournalDb::commitInternal ]:	Transaction commit  "All Finished." 
08-22 15:44:27:394 [ info sync.engine ]:	Sync run took  84 ms
08-22 15:44:27:394 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:IGNORE:C:\\Users\\Hana Gemela\\ownCloud17" to QLocalSocket(0x88dde68)
08-22 15:44:27:394 [ debug sync.localdiscoverytracker ]	[ OCC::LocalDiscoveryTracker::slotSyncFinished ]:	sync failed, keeping last sync's local discovery path list
08-22 15:44:27:394 [ info gui.folder ]:	Client version 2.6.0daily20190820 (build 12286)  Qt 5.12.4  SSL  OpenSSL 1.1.1  11 Sep 2018
08-22 15:44:27:394 [ warning gui.folder ]:	SyncEngine finished with ERROR
08-22 15:44:27:400 [ info gui.folder ]:	Folder sync result:  3
08-22 15:44:27:400 [ info gui.folder ]:	the last 3 syncs failed
08-22 15:44:27:400 [ info gui.socketapi ]:	Sending SocketAPI message --> "STATUS:IGNORE:C:\\Users\\Hana Gemela\\ownCloud17" to QLocalSocket(0x88dde68)
08-22 15:44:27:400 [ info gui.socketapi ]:	Sending SocketAPI message --> "UPDATE_VIEW:C:\\Users\\Hana Gemela\\ownCloud17" to QLocalSocket(0x88dde68)
08-22 15:44:27:400 [ info gui.application ]:	Sync state changed for folder  "http://10.42.16.185:8080/remote.php/dav/files/carol/" :  "Error"

The file is not present in Windows Explorer

[HanaGemela]

Reproduced. But I don't think I used webUI yesterday. But I run many tests so I can't be 100% sure

1. User hana shares folder called Test32 with group friends via web ui with only create and delete permissions (default permissions are no permissions)
2. User hana adds files called file.txt.txt (test files shared)
3. User dana (member of friends group) syncs the folder on the desktop sync client

Actual result: One file (out of three shared ones) has access denied

Logs shared

[ckamm]

@HanaGemela I tried reproducing, but it did work alright for me. Notable difference is that when I set up the group share with the webui by default all permissions are checked.

What do you mean with "one out of three" - you only mention one file, test.txt.txt.

[HanaGemela]

What do you mean with "one out of three" - you only mention one file, test.txt.txt.

I shared the whole folder I've uploaded on the server. It includes file.txt.txt and subfolder called Sub. Sub includes file1.txt.txt and file2.txt.txt

by default all permissions are checked.

This can be set in Settings -> Admin -> Sharing -> Default user and group share permissions

[ckamm]

I still can't reproduce the problem. Now with several files in a subfolder of the shared folder, and the default share permissions disabled.

[ckamm]

Also, if this problem happens when you set up the share via the webui it's really unlikely to be a client issue.

[HanaGemela]

Steps to reliably recreate:

1. Download a large file
2. Stop sync in the middle
3. Mark the temporary file as read-only
4. Resume the sync

[HanaGemela]

I've tested with file titled sample.txt, client 2.6.0rc1 (build 12411), macOS 10.14.6
After the test, the file is synced but greyed out. Why's that? @ckamm
It stays greyed out even after opening and I have Read&Write access to it

[HanaGemela]

Moved to 2.6.1 as it is not a blocker for 2.6.0

[ogoffart]

Looks like the file is either hidden, or still read-only. Could find out from the shell why it is gray?

[HanaGemela]

@ogoffart When the hidden files are visible, the new file is grey. When hidden files are hidden, the new file is normal black.
The incomplete downloading file is grey and once the download finishes, the file is replaced by that completely downloaded file including the colour of the file name

[michaelstingl]

@HanaGemela Could you open a new issue with the remaining things to improve? Then close here.

[HanaGemela]

Last remaining question moved to #7618