jcdufourd
commented
1 week 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 2 weeks ago
jcdufourd
commented
1 week 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
1 week ago Add handleCopiesAsOwned with value true to your object storage configuration to drop restricted permissions on copy
jcdufourd
commented
1 week 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
1 week 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
1 week ago Then if you now copy a file you should gain all permissions as the copy is now owned by you
jcdufourd
commented
1 week 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
1 week 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
1 week 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.
⚠️ 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