Client: Linux desktop sync client does not preserve execute permissions

[iliyasbasir]

Expected behavior

File permission should stay same as own cloud server

Actual Behavior

When Desktop client sync folder from oC; Permission changed for all file inside folder but folder permission stay remain as oC server.

Step to reproduce

1) created folder at oC(webconsole)
2) sync via client
3) look folder at PC where desktop client sync
4) all files permission is changed inside the folder

Server

Operating system: Ubuntu 13.10
Web server: Apache/2.4.6 (Ubuntu) Server
Database: MySQL server version 5.6.19
PHP version: PHP 5.5.3-1ubuntu2.6 (cli) (built: Jul 7 2014 16:54:32)
ownCloud version: 7.0.5
Storage backend: local
Client configuration - Can you clarify/elaborate what you mean here?
Client version: version 1.8.0
Operating system: Any Linux system (in this case, we'll use Ubuntu 14.04)
OS language: English (US)
Installation path of client: /usr/bin/{redacted}

Logs

s3:Shared/owncloud/support/github-issues/client/3188

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[craigpg]

@dragotin, adding to milestone as it's currently in the top-10.

[ckamm]

I doubt this is in scope for 1.8.2. Supporting file permissions would need updates to client and server and is more like a new feature than a bugfix. It would also need to make sure to work nicely with the different permissions systems that our client platforms (and probably storage backends!) employ.

[bboule]

So guys just so I am clear, the files as they sync down from the OC server I assume that the changing permissions (i.e. it is no longer has exe permissions) this is expected behavior? @iliyasbasir have you tested this in the lab? Assuming that is the case are we saying this is a feature request?

[dragotin]

rather than expected behaviour I'd call it a missing feature. As said before, we need a way to

1. store permissions (and possibly other file meta data, so called xattr on linux) on the server. There is no obvious way yet, @DeepDiver1975
2. agree on how we handle permissions cross platform, ie. on Windows, there is no executable flag.

That should be scheduled by product management once we have a clear picture of the scope and the functionality.

[bboule]

Understood and thank you!! We will take the suggested actions with PM!! Thanks for your help!!

[dragotin]

@bboule sorry, it was _not_ said before _here_, but somewhere else we had this topic as well... don't remember where.

[iliyasbasir]

@ckamm @dragotin this my yesterday evening testing step...still No Luck !
Bellow action is taken
1) Build Ubuntu desktop
2) Install 1.8.0 client
3) Sync
4) Permission at sync changed [file (rw-rw-r--) , Folder (drwxrwxr-x)
5) Same file at oC server as 755
Then,
1) Build .zip
2) Sync via desktop client
3) Extract some where
4) Permission cannot preserve as oC

[bboule]

OK guys I have presented the workarounds for this to the customer the workaround is one of the following: 1. Put the software in an archive and inform the user they need to extract to a location other then the OC sync folder. 2. Simply let them download, copy to another location and then add the x flag back. In the meantme @iliyasbasir can you type up the issue in a SF as a feature request?

[dragotin]

can this be closed?

[MTRichards]

Can I keep it as a feature enhancement? For tracking purposes.

[bboule]

Indeed I asked Iliyas to convert or open a new feature request I prefer he close the customer issue and open FR but either way

Sent from my iPhone

On May 19, 2015, at 1:01 PM, MTRichards [email protected] wrote:

Can I keep it as a feature enhancement? For tracking purposes.

—
Reply to this email directly or view it on GitHub.

[ogoffart]

There was an issue already before for the same thing: https://github.com/owncloud/client/issues/820

But we need support for storing metadata on the server. There is a server issue: https://github.com/owncloud/core/issues/6983

It would be nice if the server could allow arbitrary metadata that we can use to store things like local permissions

[felixboehm]

@bboule Please update status, can we remove blue?

[thor84no]

This is still an issue for me on Ubuntu 16.04 and Owncloud client 2.1.1.

Not only does it not correctly sync the permissions however, it actively removes the executable flag from all of my scripts periodically - seemingly at random. It's got so bad I'm executing a chmod +x /*.sh in my PS1 function since the flag being removed makes all of my git hooks stop executing - completely silently! It's beyond ridiculous.

[moscicki]

@ogoffart: what about we add this feature to the sync spec and later on owncloud server catches up with the implementation? Permission bit propagation is a problem for us, too.

I propose to simply add a request/response header for PUT/GET:

OC-Permission: X

Other permission bits could be added later on if relevant.

Other metadata stuff could be added later on as a separate header.

If you are worried that an extra header in PUT request could break the current owncloud server versions, then we could enable this functionality based on capability call, so any existing owncloud server would not be affected at all.

Ref. https://github.com/owncloud/core/issues/6983

[ogoffart]

that could be done. But I think it is better to have a generic metadata mechanism than adding custom headers like that.

[moscicki]

Do you have in mind some specific scheme to handle this?

[michaelstingl]

@dragotin Is this something that could find it's way in the 2.3.0 or 2.4.0 release? /cc @felixboehm @pmaier1

00006160

[michaelstingl]

that could be done

When? What are the next steps?

[pmaier1]

Probably we should work on a general "file metadata storage" concept to store all such information including permissions and data like tags or comments as well?! What do you think?

[michaelstingl]

@pmaier1 "file metadata storage" is about where to store this on the server side. But @moscicki asks about the scheme how to let the clients communicate this with the server. As soon this is defined, client implementation could start to begin, independent from server implementation.

[ogoffart]

@michaelstingl First we need metadata storage on the server and a way for clients to query it. Ideally it should be exposed as a webdav property. And it could be set with a header OC-METADATA-XXX in the PUT (a simple PROPPATCH would work too, but might be a bit slow if every file need to set a metadata.)

[moscicki]

This requires more comprehensive treatment. I started a protocol discussion here:
https://github.com/cernbox/smashbox/blob/master/protocol/metadata.md

Please contribute.

[michaelstingl]

First we need metadata storage on the server and a way for clients to query it.

No, we don't need to implement this on the server first. We only have to specify the protocol. Then we can start implementing it for the client.

[ogoffart]

@moscicki From your proposal, We don't need the GET change.

The current owncloud server already has custom webdav property. I don't know however if it will scale to ask for some custom property in every PROPFIND.
But what's missing is being able to change the metadata from the PUT call because we don't want to do a PROPPATCH for every file as that would kill performance.

[moscicki]

What if I chmod locally the file? Don't you need the PROPPATCH to propagate
just the metadata change?

I think if we draft the spec as I proposed earlier then it will be easier
to get the complete picture and make sure that there are no missing bits.

On Wed, Nov 16, 2016 at 11:42 AM, Olivier Goffart [email protected]
wrote:

@moscicki https://github.com/moscicki From your proposal, We don't need
the GET change.

The current owncloud server already has custom webdav property. I don't
know however if it will scale to ask for some custom property in every
PROPFIND.
But what's missing is being able to change the metadata from the PUT call
because we don't want to do a PROPPATCH for every file as that would kill
performance.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/owncloud/client/issues/3199#issuecomment-260913306,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAl9jUAR7KQnK2ly4oYG53cWBl5tdbBAks5q-t4VgaJpZM4EQT_W
.

---

Best regards,
Kuba

[felixboehm]

@ogoffart Next steps? Should we talk to get an agreement?

[ogoffart]

The next step is:

• Make it possible, using custom HTTP tag, to set any custom property metadata with the PUT calls.
  eg: OC-METADATA-UPERM: 0755

• Make sure that we can query custom property in every PROPFIND without causing massive CPU usage on the server. ( @PVince81 told me that he think the current server implementation might not scale)

• Also does a change in the custom property invalidate the parent directories etag?

[ogoffart]

Removing from client milestone because it depends on server feature which are not scheduled.

[RobertoFranceschini]

This is a key feature, missing this makes the synced data just not usable at all for my purposes.

[tgwaste]

Does this have a chance of ever happening? This is the one thing that keeps OwnCloud from being a Dropbox killer. They had this on day #1 :(

[michaelstingl]

Does this have a chance of ever happening?

Realistically not in 2021, sorry.

[moscicki]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

[tgwaste]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

amen. is this really such a big thing that it couldn't be solved in 6 years?

[michaelstingl]

Hello guys at owncloud, 6 years and counting.... no pressure ;-)

@moscicki Idea was, your team makes a proposal for the CS3 API's.