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

Files shared read-only are not marked read-only on the filesystem #3244

Closed
Dianafg76 opened this issue May 19, 2015 · 22 comments

Comments

@Dianafg76
Copy link

commented May 19, 2015

Steps to reproduce

  1. Open your Owncloud Web client, with the user1
  2. Create a new File, called aaa
  3. Share the Folder aaa with other user (user2)
  4. Unchecked the option 'Edit'
  5. Open your Owncloud Desktop client, with the user2
  6. Go to Open Folder "ownCloud"
  7. Wait for it to sync
  8. Open the File aaa Edit and Write something
  9. Save the File aaa
  10. Wait for it to sync

Expected behaviour

You can't Edit and Write the File aaa because you have unchecked the opcion Edit

Actual behaviour

When you Edit and Write the File aaa with the user2, Is not sync, it is appears an error
screen shot 2015-05-19 at 09 41 14

screen shot 2015-05-19 at 09 27 12

Server configuration

Version Desktop:
Version 1.8.2 (build 2369)

Web server:
{"installed":true,"maintenance":false,"version":"8.1.0.6","versionstring":"8.1 beta 2","edition":"Enterprise"}

@Dianafg76

This comment has been minimized.

Copy link
Author

commented May 19, 2015

LOGS

05-19 09:41:10:106 0x7ffdc340f580 OCC::AbstractNetworkJob::slotFinished: void OCC::AbstractNetworkJob::slotFinished() 202 "Error downloading http://XXX/remote.php/webdav/aaa.txt - server replied: Forbidden"
05-19 09:41:10:106 0x7ffdc340f580 OCC::PropagateUploadFileQNAM::slotPutFinished: void OCC::PropagateUploadFileQNAM::slotPutFinished() QUrl( "http://XXX/remote.php/webdav/aaa.txt" ) FINISHED WITH STATUS 202 "Error downloading http://XXX/remote.php/webdav/aaa.txt - server replied: Forbidden" QVariant(int, 403) QVariant(QString, "Forbidden")
05-19 09:41:10:106 0x7ffdc340f580 OCC::PropagateUploadFileQNAM::slotPutFinished: "<?xml version="1.0" encoding="utf-8"?>
<d:error xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns">
<s:exception>Sabre\DAV\Exception\Forbidden</s:exception>
<s:message/>
</d:error>
"
05-19 09:41:10:107 0x7ffdc340f580 OCC::SyncJournalErrorBlacklistRecord::update: Fatal Error condition 403 , maximum blacklist ignore time!
05-19 09:41:10:107 0x7ffdc340f580 OCC::SyncJournalErrorBlacklistRecord::update: blacklisting "aaa.txt" for 86400 , retry count 1
05-19 09:41:10:107 0x7ffdc340f580 OCC::SyncJournalDb::updateErrorBlacklistEntry: set blacklist entry for "aaa.txt" 1 "Error downloading http://XXX/remote.php/webdav/aaa.txt - server replied: Forbidden" 1432021270 86400 1432021267 "937910ba40172b396ea26dd4e7169609"
05-19 09:41:10:108 0x7ffdc340f580 OCC::SyncEngine::slotJobCompleted: void OCC::SyncEngine::slotJobCompleted(const OCC::SyncFileItem &) "aaa.txt" INSTRUCTION_SYNC 2 "Error downloading http://XXX/remote.php/webdav/aaa.txt - server replied: Forbidden"
05-19 09:41:10:112 0x7ffdc340f580 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:ERROR:/Users/Diana/ownCloud/aaa.txt"
05-19 09:41:10:116 0x7ffdc340f580 OCC::SyncJournalDb::walCheckpoint: void OCC::SyncJournalDb::walCheckpoint() took 0 msec
05-19 09:41:10:116 0x7ffdc340f580 OCC::SyncJournalDb::commitInternal: void OCC::SyncJournalDb::commitInternal(const QString &, bool) Transaction commit "All Finished." 
05-19 09:41:10:117 0x7ffdc340f580 OCC::SyncEngine::finalize: CSync run took 558
05-19 09:41:10:117 0x7ffdc340f580 OCC::BandwidthManager::~BandwidthManager: virtual OCC::BandwidthManager::~BandwidthManager()
05-19 09:41:10:117 0x7ffdc340f580 OCC::Folder::slotSyncFinished: -> SyncEngine finished without problem.
05-19 09:41:10:118 0x7ffdc340f580 OCC::Folder::bubbleUpSyncResult: Processing result list and logging took 0 Milliseconds.
05-19 09:41:10:118 0x7ffdc340f580 OCC::sendOsXUserNotification: void OCC::sendOsXUserNotification(const QString &, const QString &) "Sync Activity" "aaa.txt could not be synced due to an error. See the log for details."
05-19 09:41:10:118 0x7ffdc340f580 OCC::Folder::bubbleUpSyncResult: OO folder slotSyncFinished: result: 3
05-19 09:41:10:118 0x7ffdc340f580 OCC::Folder::slotSyncFinished: ** error Strings: ("aaa.txt: Error downloading http://XXX/remote.php/webdav/aaa.txt - server replied: Forbidden")
05-19 09:41:10:119 0x7ffdc340f580 OCC::Folder::slotSyncFinished: * owncloud csync thread finished with error
05-19 09:41:10:119 0x7ffdc340f580 OCC::Folder::slotSyncFinished: the last 1 syncs failed
05-19 09:41:10:119 0x7ffdc340f580 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:ERROR:/Users/Diana/ownCloud/"
05-19 09:41:10:119 0x7ffdc340f580 OCC::SocketApi::sendMessage: SocketApi: Sending message: "UPDATE_VIEW:/Users/Diana/ownCloud/"
05-19 09:41:10:120 0x7ffdc340f580 OCC::ownCloudGui::slotComputeOverallSyncStatus: Folder in overallStatus Message: OCC::Folder(0x7ffdc5961580) with name "ownCloud"
05-19 09:41:10:120 0x7ffdc340f580 OCC::ownCloudGui::slotSyncStateChange: Sync state changed for folder "ownCloud" : "Error"
05-19 09:41:10:145 0x7ffdc340f580 OCC::SocketApi::command_RETRIEVE_FILE_STATUS: void OCC::SocketApi::command_RETRIEVE_FILE_STATUS(const QString &, QLocalSocket *) "/Users/Diana/ownCloud/.owncloudsync.log"
05-19 09:41:10:145 0x7ffdc340f580 OCC::SocketApi::sendMessage: SocketApi: Sending message: "STATUS:IGNORE:/Users/Diana/ownCloud/.owncloudsync.log"
05-19 09:41:10:322 0x7ffdc340f580 OCC::FolderMan::slotFolderSyncFinished: <===================================== sync finished for "ownCloud"
@dragotin

This comment has been minimized.

Copy link
Contributor

commented May 19, 2015

This sounds like a regression. The wanted behaviour is: The file coming from a non editable share should be set to read only on the harddisk of the client. If that is changed manually to rw again (which is of course possible) the client should not even try to upload it, but report that the change can not be uploaded, restore the original file and move the local change to a conflict file.

@dragotin dragotin added this to the 1.8.2 - Bugfix 2 milestone May 19, 2015

@ckamm

This comment has been minimized.

Copy link
Member

commented May 20, 2015

@dragotin I don't think we set non-editable shares to read-only on the local file system yet. Is this something that'd be ok to add to 1.8?

I'll try to reproduce the problem with the rename-to-conflict-and-revert behavior. That one should definitely exist.

@ckamm

This comment has been minimized.

Copy link
Member

commented May 21, 2015

I could reproduce the problem with the client trying to upload new data to a read-only share.

@ckamm

This comment has been minimized.

Copy link
Member

commented May 21, 2015

In my reproduction with server 8.0.2, it's caused by a server issue: it reports the read-only share's permissions as <oc:permissions>SRDNVW</oc:permissions>, including the W. I'll now retry with 8.0.3.

@ckamm

This comment has been minimized.

Copy link
Member

commented May 21, 2015

Same response with server 8.0.3.

@danimo

This comment has been minimized.

Copy link
Contributor

commented May 21, 2015

/cc @DeepDiver1975: Server sends wrong permissions in above scenario. Needs investigation by server team.

@ckamm

This comment has been minimized.

Copy link
Member

commented May 21, 2015

I've moved the server part to owncloud/core#16492.

@Dianafg76 Dianafg76 changed the title [Sharing] When you share a File with two user and unchecked the opcion EDIT, when it's Sync in DESKTOP you can edit and write the File [Sharing] When you share a File with two users and unchecked the opcion EDIT, when it's Sync in DESKTOP you can edit and write the File May 21, 2015

@ckamm ckamm changed the title [Sharing] When you share a File with two users and unchecked the opcion EDIT, when it's Sync in DESKTOP you can edit and write the File Files shared read-only are not marked read-only on the filesystem May 27, 2015

@ckamm ckamm removed the Server Involved label May 27, 2015

ckamm added a commit to ckamm/owncloud-client that referenced this issue May 27, 2015

@ckamm

This comment has been minimized.

Copy link
Member

commented May 27, 2015

A discussion with @guruz @ogoffart @PVince81 has shown that changing local file permissions based on server permissions has several complications:

  • Changes in share permission need to be propagated to the client so it can adjust the file permissions. Currently changing share permissions does not trigger an etag change. This requires a server change.
  • When a file that used to be read-only becomes writable, we need to be careful about which write permissions are added. Enabling the write permissions that are in umask could be the right approach.
@MTRichards

This comment has been minimized.

Copy link

commented Jun 19, 2015

Same issue:
#3137

@ckamm ckamm added the sev2-high label Jul 1, 2015

@ckamm ckamm modified the milestones: 2.1-next, 2.0 - Multi-account Jul 1, 2015

@ckamm

This comment has been minimized.

Copy link
Member

commented Jul 1, 2015

Moved to 2.1 because the server dependencies will be in 8.2.

@MTRichards

This comment has been minimized.

Copy link

commented Aug 10, 2015

Changes in share permission need to be propagated to the client so it can adjust the file permissions. Currently changing share permissions does not trigger an etag change. This requires a server change.

If we have a true dependency on the server side, not sure this can be added for 2.1.

@ogoffart

This comment has been minimized.

Copy link
Collaborator

commented Oct 22, 2015

(the server part is done in 8.2)

@ckamm

This comment has been minimized.

Copy link
Member

commented Oct 29, 2015

I've tested this on 8.2 and it does indeed work, the etag changes on share-permission change and the client notices and updates the permissions stored in the database.

  • 'can share': +R on file and folder
  • 'create': +CK on folder
  • 'change': +W on file
  • 'delete': +DNV on file

That means we can now watch the W permission of a file and adjust the local permissions to reflect that.

@ogoffart

This comment has been minimized.

Copy link
Collaborator

commented Oct 29, 2015

maybe iff account()->serverVersionInt() >= 0x080200

Edit: actually, i think we should do it in any cases, since we would anyway try to even restore files that are modified if the database tells us that the files are read only

@ckamm

This comment has been minimized.

Copy link
Member

commented Nov 4, 2015

@ogoffart Excellent point!

@ckamm

This comment has been minimized.

Copy link
Member

commented Nov 10, 2015

Current status:

  • Files shared read-only are correctly marked as such in the filesystem
  • Permission updates on the server are reflected in the local permissions
  • There's a server bug that causes file-shares to not update their permissions correctly owncloud/core#20426
  • We should also adjust the permissions of shared directories where possible
@ckamm

This comment has been minimized.

Copy link
Member

commented Nov 10, 2015

Setting shared-folder permissions:

  • Windows has no equivalent
  • With unix-like permissions 'w' on folders is equivalent to CK on the folder and DNV on each contained file. So a correct solution would need to check the permissions of all contained files. It also introduces problems with downloads, as we can no longer create files in the folder.

We'll not go there for now.

@ckamm ckamm added the ReadyToTest label Nov 10, 2015

@Dianafg76

This comment has been minimized.

Copy link
Author

commented Nov 11, 2015

I tested this issue and appears the same error:
screen shot 2015-11-11 at 10 19 22

LOG:

11-11 10:14:37:623 0x7fde1cd57cf0 csync_walker: file: ownclouds://docker.oc.solidgear.es:xxx/remote.php/webdav/aaafile.txt [file_id=00005266ocmfgtuqq44w size=5]
11-11 10:14:37:624 0x7fde1cd57cf0 _csync_detect_update: Database entry found, compare: 1447233195 <-> 1447233195, etag: 19fa12fa522bcb02963945aec77de120 <-> 19fa12fa522bcb02963945aec77de120, inode: 0 <-> 4767171, size: 5 <-> 5, perms: SRDNVW <-> SRDNVW, ignore: 0
11-11 10:14:37:657 0x7fde1a5318c0 OCC::ownCloudGui::slotSyncStateChange: Sync state changed for folder  "ownCloud1" :  "Sync Running"
11-11 10:14:37:657 0x7fde1a5318c0 OCC::SyncEngine::slotItemCompleted: void OCC::SyncEngine::slotItemCompleted(const OCC::SyncFileItem &, const OCC::PropagatorJob &) "aaafile.txt" INSTRUCTION_ERROR 6 "The item is not synced because of previous errors: Error downloading https://docker.oc.solidgear.es:53166/remote.php/webdav/aaafile.txt - server replied: Forbidden (Sabre\DAV\Exception\Forbidden)"

Desktop v ownCloud-2.1.0.2865-nightly20151110.pkg
Server v {"installed":true,"maintenance":false,"version":"8.1.4.0","versionstring":"8.1.4 RC1","edition":""}

@Dianafg76 Dianafg76 added ReadyToTest and removed ReadyToTest labels Nov 11, 2015

@Dianafg76

This comment has been minimized.

Copy link
Author

commented Nov 11, 2015

With Dektop v ownCloud-2.1.0.2871-nightly20151111.pkg I can see the same error

@ckamm

This comment has been minimized.

Copy link
Member

commented Nov 11, 2015

@Dianafg76 You are running into the server problem owncloud/core#20426 of the permissions not being advertised correctly. Try sharing a directory instead.

@KUTlime

This comment has been minimized.

Copy link

commented Jan 11, 2016

I believe that I have an opposite issue with version 2.1.0 build 5683.
Recently, I receive many sync error because Owncloud marks the file with read only permission and after that it cause the sync error. For example:
PC 1 - I open some PDF file.
PC 2 - Owncloud reports the sync error because it can't synchronize the PDF file which is already present on PC 2, but not it have a read-only permission.
Similar problems with files with codes. Really annoying.

It is related or it is some other bug?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.