Own cloud changes file mode of synced files

[TrayKnots]

Hi,
I just noticed that a file I have synced has changed.
I had the file created on Linux Mint and synced it via the Desktop Client. The file I created had the file mode 755 (read, write, execute for owner and read, execute for groups and others).
When I synced it down on my Windows 11 client inside WSL with Ubuntu 20.04, I received the file in the mode 644 (read, write for owner, read for group and others).

This seems like a significant change. I couldn’t find anything about the file mode of files. Does Owncloud actually try to keep the file modes or is this simply out of scope for Owncloud?

Steps to reproduce

1. Create a file on a linux client. Chmod it to 755
2. Sync file to server
3. Sync file to a second client, check the file mode with ls -l

Expected behaviour

The file modes shouldn’t change and still be 755

Actual behaviour

The file modes are set to 644

Server configuration

Operating system:
Ubuntu Server running recommended docker compose file with the latest tag

Web server:
Default compose file, apache

Database:
Default compose file, MariaDb

PHP version:
Not sure, current latest docker container

ownCloud version: (see ownCloud admin page)
10.11.0.6

Updated from an older ownCloud or fresh install:
Fresh install, docker image, new database

Where did you install ownCloud from:
docker hub

List of activated apps:

Default apps plus the default encryption app.

Are you using external storage, if yes which one: no

Are you using encryption: yes

Are you using an external user-backend, if yes which one: none

Client configuration

Operating system: Linux Mint and Windows 11 WSL Ubuntu 20.04

[LinkP]

Windows doesn’t understand Linux file permissions…

[TrayKnots]

It’s Windows 11 WSL Ubuntu 20.04.
This is running on a linux file system. Doesn’t even touch the Windows file system.

[jvillafanez]

I don’t think ownCloud handles those permissions, and I don’t think there is any need for that. I mean, ownCloud syncs YOUR files (or the files you can access) into YOUR account.

In addition, it’s expected that you sync the data from the server into a completely different system. It might not have the same user account for you, neither the same users or groups, so even if you want to keep “execute permission for group blablabla”, the group might not exists or it could have different members (which could be a security risk)

I’d say it’s out of scope. I’m pretty sure that the desktop client won’t touch the permissions and it just tries to create the files. Those are likely the default permissions that are used when a file is created.

[TrayKnots]

@jvillafanez

I’d say it’s out of scope.

Yeah, I was afraid this is the case. Darn, than it doesn’t fulfill my use case. I wanted to be able to stand up from my desktop, grab my laptop and just continue working without having to remember to git commit and push. I thought, as long as I sync my whole .git directory, it should even sync which branch I have checked out…

Too bad, but yeah, I see why this would be out of scope. Good argument. I go and try to find a solution for my usecase elsewhere.

Thank you for your answer.