jcdufourd
commented
4 months ago I also tried removing one such file with:
sudo -u www-data php occ files:delete 87859 -f
and the answer is
File cannot be deleted, insufficient permissions.
Open jcdufourd opened 4 months ago
jcdufourd
commented
4 months ago I also tried removing one such file with:
sudo -u www-data php occ files:delete 87859 -f
and the answer is
File cannot be deleted, insufficient permissions.
susnux
commented
4 months ago Add handleCopiesAsOwned with value true to your object storage configuration to drop restricted permissions on copy
jcdufourd
commented
4 months ago Thank you @susnux for your suggestion. This option addition does not change the current situation: existing copies are still not changeable. This does not change a new situation entirely constructed after the option has been added: new copies in a new folder newly shared are still not changeable. (Note: only steps 3-4-5 above were done again, not the initial creation of read-only documents and folder = step 1-2) (Note2: even redoing all 5 steps changes nothing: the copied files are unchangeable by anyone)
susnux
commented
4 months ago You need something like this:
// ...
'objectstore' => [
'class' => '\\OC\\Files\\ObjectStore\\S3',
'arguments' => [
'handleCopiesAsOwned' => true,
// ...
],
],
// ...You need something like this:
// ... 'objectstore' => [ 'class' => '\\OC\\Files\\ObjectStore\\S3', 'arguments' => [ 'handleCopiesAsOwned' => true, // ... ], ], // ...
This is exactly what I have already done (but "your" option is last in my array of arguments).
susnux
commented
4 months ago Then if you now copy a file you should gain all permissions as the copy is now owned by you
jcdufourd
commented
4 months ago Then if you now copy a file you should gain all permissions as the copy is now owned by you
When I now copy a read-only file, the copy is still read-only
susnux
commented
4 months ago Have you restarted your FPM processes (so the config is reload / not cached)? Because I tested it right now and with this option copies gain all permissions.
jcdufourd
commented
4 months ago I have no idea how to check this. I am using the docker version of nextcloud+onlyoffice and fpm is not a service. I only know I am using fpm because the image I use is called 29-fpm.
joshtrichards
commented
4 months ago I have no idea how to check this. I am using the docker version of nextcloud+onlyoffice and fpm is not a service. I only know I am using fpm because the image I use is called 29-fpm.
Restarting the Docker container containing fpm should suffice.
@susnux Think we should document #41565 / #41564?
nextcloud-command
commented
3 months ago This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.
jcdufourd
commented
2 months ago I have no idea how to check this. I am using the docker version of nextcloud+onlyoffice and fpm is not a service. I only know I am using fpm because the image I use is called 29-fpm.
Restarting the Docker container containing fpm should suffice.
I have restarted the server multiple times since then. I even updated the nextcloud version. The problem stays the same: when I copy a read-only file that I own, the copy is owned by me and fully accessible; when I copy a read-only file that I do not own, the copy stays read-only. Note: all the files are stored on S3 which could affect the behaviour.
My nextcloud version is now 29.0.6
joshtrichards
commented
2 months ago Can you post the output of occ config:list system from inside your container where you've made the change?
The Docker image uses multiple config files. Maybe something isn't working as expected here.
jcdufourd
commented
2 months ago {
"system": {
"memcache.local": "\\OC\\Memcache\\APCu",
"apps_paths": [
{
"path": "\/var\/www\/html\/apps",
"url": "\/apps",
"writable": false
},
{
"path": "\/var\/www\/html\/custom_apps",
"url": "\/custom_apps",
"writable": true
}
],
"objectstore": {
"class": "\\OC\\Files\\ObjectStore\\S3",
"arguments": {
"bucket": "mkpfrance-documents",
"region": "eu-west-3",
"hostname": "",
"port": "443",
"objectPrefix": "urn:oid:",
"autocreate": false,
"use_ssl": true,
"use_path_style": false,
"legacy_auth": false,
"key": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"handleCopiesAsOwned": true
}
},
"instanceid": "***REMOVED SENSITIVE VALUE***",
"passwordsalt": "***REMOVED SENSITIVE VALUE***",
"secret": "***REMOVED SENSITIVE VALUE***",
"trusted_domains": [
"home.dufourd.org:33333",
"nginx-server"
],
"datadirectory": "***REMOVED SENSITIVE VALUE***",
"dbtype": "mysql",
"version": "29.0.6.1",
"overwrite.cli.url": "https:\/\/home.dufourd.org:33333",
"installed": true,
"defaultapp": "files",
"auth.webauthn.enabled": false,
"onlyoffice": {
"verify_peer_off": true,
"DocumentServerUrl": "\/ds-vpath\/",
"DocumentServerInternalUrl": "https:\/\/home.dufourd.org:33333\/ds-vpath\/",
"StorageUrl": "http:\/\/nginx-server\/",
"jwt_secret": "***REMOVED SENSITIVE VALUE***",
"jwt_header": "AuthorizationJwt",
"allow_local_remote_servers": true
},
"overwriteprotocol": "https",
"upgrade.disable-web": true,
"maintenance": false,
"dbname": "***REMOVED SENSITIVE VALUE***",
"dbhost": "***REMOVED SENSITIVE VALUE***",
"dbuser": "***REMOVED SENSITIVE VALUE***",
"dbpassword": "***REMOVED SENSITIVE VALUE***",
"mysql.utf8mb4": true,
"loglevel": 0,
"app_install_overwrite": [
"backup",
"hsts"
],
"maintenance_window_start": 1,
"htaccess.RewriteBase": "\/"
}
}
⚠️ This issue respects the following points: ⚠️
Bug description
I start with a folder A with read-only sharing for everyone, and add some files including a file B to it. A and B are created as an admin.
Then, as a normal user, I create a folder C with full-editing sharing with a group, then copy file B into folder C. The resulting file is D.
The permissions on file D are read-only, and I cannot find a way to remove it. My expectation is that the user who made the copy should be able to remove it. The admin account, with which D is shared with full-editing share from folder C, also cannot remove the file, and I think it should also have.
With the outlined process, files are created that noone can get rid of. I believe that is a bug.
Steps to reproduce
Expected behavior
There should be a way for the user who made the copy to remove the file
Installation method
Community Docker image
Nextcloud Server version
29
Operating system
Debian/Ubuntu
PHP engine version
PHP 8.2
Web server
Nginx
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
None
Are you using the Nextcloud Server Encryption module?
None
What user-backends are you using?
Configuration report
List of activated Apps
Nextcloud Signing status
Nextcloud Logs
Additional info
No response