GNOME Bugzilla – Bug 371025
"Apply permissions to enclosed files"-function doesn't work.
Last modified: 2015-06-23 17:38:36 UTC
Please describe the problem:
The "Apply permissions to enclosed files"-function in Permissions menu doesn't work properly.
The permissions of a directory aren't applied to the enclosed files.
Steps to reproduce:
1. Right-Click on directory
2. Choose "Properties"
3. Then Click on "Permissions" tab
4. Change permissions
5. Click on "Apply permissions to enclosed files"
6. Check the files in the directory, if their permissions are changed to the permissions of the directory
The permissions aren't changed! "Apply permissions to enclosed files"-function doesn't work.
The permissions of the enclosed files will be changed to the same permissions of the upper directory.
Does this happen every time?
https://bugs.launchpad.net/nautilus/+bug/165113 describes a similar issue
"Open gksudo nautilus
Choose a folder, right click, choose properties
Change from root.root to local user for all choices
Change permissions to create & delete
Click the "Apply permissions to enclosed files"
The permissions and ownership are changed on the folder, but not on any of the subfolders or files below."
I confirm on Hardy.
With or not gksudo this problem persist...
Bug confirmed on Ubuntu 8.10.
Recommend as bug appears to be "un-fixable" by gnome devs removal of GUI button to avoid function and encourage CLI chmod use instead.
Would like to know why this bug is a year old and still present in the latest version of gnome?
(In reply to comment #3)
> Bug confirmed on Ubuntu 8.10.
> Recommend as bug appears to be "un-fixable" by gnome devs removal of GUI button
> to avoid function and encourage CLI chmod use instead.
> Would like to know why this bug is a year old and still present in the latest
> version of gnome?
avoid function - avoid confusion, late nights effect grammer and sentence structure!
*** Bug 562624 has been marked as a duplicate of this bug. ***
Confirming for duplicates.
The bug I reported (bug 562624) has been linked to this bug. However this bug report was posted two years ago. So is this a bug or are people miss-understanding the apply permissions feature. If in fact this is a bug then why hasn't it been fixed in newer releases?
Note that the "Apply permissions to enclosed files" button does NOT apply the permissions of the directory, it applies the permissions specified in the "File access" dropdowns. So the way I read this bug report, it should be invalid as the "Apply permissions to enclosed files" button does work as intended. Can someone confirm that my understanding is correct?
This still seems like it's an issue.
Firstly I can't seem to select appropriate file permissions and then apply those to files within that directory, as described in the comment above.
Secondly I would expect that if I changed the group owner then that change would also be propagated to the files contained inside.
I propose that this appears to be an issue of usability; what happens vs. what peoples expectations are. Perhaps this feature needs looking at again and the information presented in a clearer, easier to grasp way.
Filezilla has implemented this in a sensible way. When changing properties on remote directory you are given the option to apply the changes to files in that directory, files recursively or files+folders recursively.
Trawling the net it seems like it's enough of an issue to have warranted a place on ubuntu's brainstorm along with a separate ongoing thread in the forums:
We've just done some major changes around this in master. Can you verify that this is still an issue?
Haven't tested with master as i wouldn't know where to start, however I can provide an update based on stock Ubuntu 12.04.
Works for me: Clicking "Apply permissions to enclosed files" happily applies 'Access' and 'Execute' permissions properly to enclosed files.
Not working for me: Changing the group is only applied to the current folder and does not recurse to any files contained within that folder. Personally I would expect that upon clicking "Apply permissions to enclosed files" the new group ownership permissions would be applied to all enclosed files; however this is just my opinion.
And it is not working again with nautilus 3.6.3 on Ubuntu13.04 64bit raring.
So, if I understood this bug correctly, it is about the "Owner" and "Group" of the folder not being applied to enclosed files when "Apply permissions to enclosed files" button is pressed. Whether the button was supposed to do that or not, it's a fair expectation that it would. The interface was very ambiguous either way.
But this "Apply permissions to enclosed files" button is no longer available, since nautilus 3.6. Now, the "Permissions" tab lets us change the permissions of the folder, and there is a "Change Permissions of Enclosed Files" button, which brings up a dedicated dialog. The interface of this dialog is much more explicit on its scope. It is still not possible to change ownership or group of enclosed files (nor any other selection of multiple files: bug 133823), but the interface no longer suggests that this should be possible.
I propose resolving this report as obsoleted by UI changes.
(In reply to comment #12)
Can you elaborate on what is not working?
Hi Antonio, hard to answer your question after a half year.
WhenI remember correct I have had ment:
Works for me: Clicking "Apply permissions to enclosed files" happily applies
'Access' and 'Execute' permissions properly to enclosed files.
from comment 11.
May be the problem is gone on the Ubuntu platfrom during time. I have had problems during developmant phase. Sry, no time to test now.
Thank you for your reply. If it fails to apply changes to read/write/execute permissions (not talking about changing owner/group), then this bug is still valid.
Can anyone verify that this is still an issue?
Hey Antonio/William, appreciate it's been a while but made a note to follow this up for you when i got round to updating my distro.
So on Ubuntu 13.10 I can say that:
Applying permissions works as expected for the individual files/folders.
The 'Change Permission for Enclosed Files' button now brings up a window where you can set RWX permissions for child files & folders. One thing I want to point out though is that the label of the button should really be changed to reflect that it's possible to change the permissions of enclosed *folders* as well as files.
As you mentioned the interface changes mean behaviour is more explicit in its scope/feature.
Previously there was a button that said 'Change Permission for Enclosed Files' however clicking on it did nothing but the expected behaviour was that it would apply the permissions & owner/group listed above it to any enclosed files.
The other part of this report was concerned with an inability to recursively change the owner/group for enclosed files.
Such behaviour would be particularly useful given that it's a basic action that currently isn't possible without resorting to the command line and has a definite use-case given that Windows has extensive permissions management. Also identical recursive owner/group behaviour is already present Filezilla.
With the way things are currently this could be regarded as more of a feature request now, however it's also possible this report provides the best context and opportunity for implementing such a feature.
(In reply to mail from comment #16)
> Applying permissions works as expected for the individual files/folders.
Indeed. I'm thus closing this bug as RESOLVED FIXED.
> The 'Change Permission for Enclosed Files' button now brings up a window
> where you can set RWX permissions for child files & folders. One thing I
> want to point out though is that the label of the button should really be
> changed to reflect that it's possible to change the permissions of enclosed
> *folders* as well as files.
Please file a new bug report for that, and try to come up with a suggestion for the new wording of the label.
> The other part of this report was concerned with an inability to recursively
> change the owner/group for enclosed files.
> With the way things are currently this could be regarded as more of a
> feature request now, however it's also possible this report provides the
> best context and opportunity for implementing such a feature.
Please file a new bug report for that and if you really think this one provides useful info, either copy the relevant bits (summed up) or link to it.