gksudo nautilus won't set ownership/permissions on files below

Thanks for reporting this bug and making Ubuntu better.

I can confirm what you described. I am setting it to "confirmed" and assigning package "nautilus"

thank you for your bug report, could you try if that's still an issue using hardy?

I can still confirm this behavior in Hardy.
Exact same steps to reproduce and outcomes as the reporter has outlined.

do you have the issue when not using sudo?

Yes, when not using gksudo the permissions do not change either (on files in my home directory).

http://bugzilla.gnome.org/show_bug.cgi?id=371025 seems similar

It is my opinion that this bug even though of low importance should have been fixed as the end result is a function which does not work. If the bug cannot be resolved then would it be possible to remove the button to avoid confusion as this bug is present in the last three ubuntu releases!

I would also like to know why exactly this bug has not been addressed?

GUI fault, should have been fixed for newest ubuntu, hasn't!

It is still a bug in 9.04 beta. It has become a problem for my JungleDisk. All of the information in it is locked as root.
This should become a high priority bug just because it has been around so long.

This bug is still apparent as of this date and is becoming increasingly annoying. I recall this used to work before. I also recall the functionality of this option working with my prior (approx 3 years ago) fedora distribution. After almost a year and a half it continues to remain unfixed and I have clients considering changing distros or OS.

I recommend switching to a desktop manager which is capable of changing permissions properly such as KDE.
I fully agree that it is ridiculous that this simple bug has been left unfixed for so long!

you can switch distros that will not make a difference this code is coming from GNOME

@ Sebastien Bacher
Which is why I suggested switching to a different desktop manager.
Switching ditribution may only solve this problem if said distribution is not using the gnome desktop manager!

The inability to modify the permissions to files in a given directory, even though it's advertised by a button, is definitely a "paper cut". New users will not be able to chmod from a terminal.

Thank you for bringing this bug to our attention. Unfortunately a paper cut should be a small usability issue that affects many people and is quick and easy to fix. I'm afraid this bug can't be addressed as part of this project. Bugs encountered after running gksudo nautilus do not affect most users' default Ubuntu 9.10 experience.

Thanks David for looking into this. I still have to disagree and I do believe this should be considered a "paper cut". As stated above by Greg Grossmeier, this bug is not just limited to users trying to change permissions from root using gksudo. This bug also affects users trying to change permissions of their own files using Nautilus. Please try changing the group permissions of a directory in your own home directory which has nested directories and files. Then choose the "Apply permissions to enclosed files" option within Nautilus. Permissions will stay the same and it will not work for you. To me this is a huge bug since a new user has no other option to change permissions besides opening up a terminal.

Either this bug needs to be fixed or the button should be removed. I hope the bug is fixed because how else is a new Ubuntu user going to change permissions?

This bug does not just effect users running nautilus under root prilages but also normally whilst logged in to their prospective user accounts.

Why has this bug not been fixed?
Surely this bug should have been fixed already, especially as a button advertises this feature but does not function.

Therefore any unknowing user may not understand why when pressing the "Apply permissions to enclosed files" button the permissions of enclosed files have not been changed!

It is an annoyance that this button is still non functional even in the new release of ubuntu 9.04 especially as other DM's and OS's have similar features functional!

I propose disabling the button in an update to prevent any confusion in the future.

BeigeGenius, *all* bugs should have been fixed already.

I am still not convinced that this is an easy-to-fix usability bug affecting most users. Can someone please give some user stories explaining how and when users are confronted with this bug?

Remember, just because a bug is not a paper cut, does not mean that it's not an important usability bug. It just means that it's not going to be addressed as part of the hundredpapercuts project. It looks like this bug is already known and being tracked upstream.

@David Siegel Well how about when a user wants/ needs to change the permissions not only of the containing folder but also all files and folders contained within said folder?
The current and only possible way of doing this on a distro using gnome is to use chmod in the terminal!

"Apply permissions to enclosed files" has for as long as I know never been functional in gnome and looks like it won't be for a long time!

I'm going to make the leap and mark this bug as invalid. I hope it's not premature...let me explain.

First, I created the following 'test' directories and files under my home directory:

[drwxr-xr-x johndoe johndoe ] ./permissions_test
|-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/apple
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/apple/seed_a
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/apple/seed_b
| `-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/apple/seed_c
|-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/grape
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_a
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_b
| `-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_c
`-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/plumb
    |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_a
    |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_b
    `-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_c

I then completed the following steps:

1) Open up Nautilus (non-gksudo)
2) Right click on the the "apple" directory and choose properties --> Permissions (tab)
3) Change the "Others/File Access" from "---" to "None"
4) Click "Apply Permissions to Enclosed Files" - This MUST be done right after changing the permission setting to "None". Do not click close first!!!

Now you will see that the permissions to the files under apple are now changed. The default read permission has been removed.

[drwxr-xr-x johndoe johndoe ] ./permissions_test
|-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/apple
| |-- [-rw-r----- johndoe johndoe ] ./permissions_test/apple/seed_a
| |-- [-rw-r----- johndoe johndoe ] ./permissions_test/apple/seed_b
| `-- [-rw-r----- johndoe johndoe ] ./permissions_test/apple/seed_c
|-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/grape
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_a
| |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_b
| `-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/grape/vine_c
`-- [drwxr-xr-x johndoe johndoe ] ./permissions_test/plumb
    |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_a
    |-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_b
    `-- [-rw-r--r-- johndoe johndoe ] ./permissions_test/plumb/pit_c

Here's one more example.

1) Right click on the the "permissions_test" directory and choose properties --> Permissions (tab)
2) Change the "Group/Folder Access" from "Access Files" to "Create and delete files"
3) Click "Apply Permissions to Enclosed Files" - This does NOT need to be done at the same time. You can click "close" and re-open the properties window and click "Apply Permissions to Enclosed Files". Folder access settings seem to be retained whereas the file access settings are not.

Now here are the results. As you can see all the sub-directories now have read/write/execute for the group properties where before they had just read/execute access.

[drwxrwxr-x johndoe johndoe ] ./permissi...

pjman's explanation notwithstanding, this is a bug and a particularly annoying one at that.
Not fixing this for years reflects poorly on Ubuntu and Gnome.

Here is just one way the bug can be reproduced:
gksudo nautilus
copy a directory (owner is "someone", group is "someone") from one partition to another
the directory in the destination partition will have the owner as root and the group as root
right click the destination directory in gksudo nautilus go to Properties > Permissions
click on Apply Permissions to Enclosed Files
All the enclosed files will now have the owner and group as root

Now, right click the destination directory in gksudo nautilus and change the owner and group to "someone"
Click on Apply Permissions to Enclosed Files

*Now, the owner and group of the directory is changed to "someone".
However, the owner and group of the files in the directory remains root.*
This is the BUG.

The only way to change the owner and group of the enclosed files now, is to use sudo chown -R on the destination directory, because it can't be done in nautilus using "Apply Permissions to Enclosed Files"

Hi,

I agree this had me stumped for a few days trying to set permissions. Can you please just give the work around in here till it is fixed. I think the button is a great idea but if it does not work it is better not to have it. It really wasted a lot of my time.

I am working in Fedora 11

Thanks.

Now that it comes to user-friendly system, we would like to have a working function.

My opinion mode on:

Damn....I was hanging around tryin to fix another inheritance problem and i found this(which occurred to me too) "old friend"...guys, besides Larson's explanation here we're talking about user friendlyness(hope it's wrote the correct way)...

After years spent working on M$ systems the last month I *totally* switched to linux(3 machines)....it's beautifull, really....better than M$...thou still a little bit hard....

I can put myself under total noobish related to ubuntu...but...think about someone which is even more noobish than me...i'm a ms sys admin, c#/tSql/Vb programmer....and still I find some things difficult to be done, think about someone which barely knows how to light up a screen =)

If a button says "Destroy the world", damn, it has to do that...and not only blow up the poles if pressed while standing on one foot touching the nose with one finger XD

Thanks for reporting this bug. However, I think it is invalid because the "Apply permissions to enclosed files" button is not meant to apply the directory's permissions to the enclosed files, it is meant to apply the permissions specified in the "File access" drop-down boxes to the enclosed files. In this context, the "Apply permissions to enclosed files" does work as expected. See the attached screenshot to see what I mean.

Confirming that this issue/confusion is still present in Ubuntu 8.04.4 LTS Desktop.

@Bruno Girin: If this is the case. Then it's very confusing for me. I mean I'm not a coder but user. From my user point of view "Apply permissions to enclosed files" means "Apply permissions to both enclosed files and folders".

About renaming the current button to "Apply permissions to enclosed files only"
And adding a new button right below and name it "Apply permissions to both enclosed files and folders"

So there would be two buttons
   "Apply permissions to enclosed files only"
   "Apply permissions to both enclosed files and folders"

Personally I have no use for the first button. It's the second one that would be useful to me. Command line is to hard for me. I need something visual/UI.

@all: Ubuntu user interface is not able to do that yet. Here is a easy work around for those who don't use command line.

STEPS
Installing 'PCMan File Manager' from the repositories. It's a sweet little lightweight file manager (ordinarily part of the LXDE desktop, but it's modular).

Navigate to the following Ubuntu's menu APPLICATIONS > SYSTEM TOOL > PCMAN FILE MANAGER

Navigate to the folder you want to edit the permissions. Select the folder with one left click.

Navigate to the following PCMAN FILE MANAGER's menu TOOL > OPEN CURRENT FOLDER AS ROOT.

Navigate to the following PCMAN FILE MANAGER's menu FILE > FILE PROPERTIES

Type in the OWNER

Type in the GROUP

Choose permissions for all the files in that folder.

Make sure SET UID and SET GID boxes are checked.
Note: UID stands for USER ID. GID stands for GROUP ID. Do not check STICKY unless you know what you're doing.

Click on OK button.

PCMAN FILE MANAGER will ask if 'Do you want to recursively apply these changes to all files and sub-folders?' This is what you want to do so click on YES button.

That's it. You have successfully changed all files and sub-folders permissions.

My Setup:
Ubuntu 10.04 64bit, kernel v2.6.32-25-generic, standard release gnome desktop.

This bug is present on my computer. I mainly encounter it because I share my computer with my wife. She has her account and I have mine. I am the system administrator of my computer, and when the need arises to transfer a file or make a shared director for doing such. Often times the files that appear in that share folder or transfered file end up with root permissions only. As such I have to change the ownerships and groups back to something that can be viewed and shared by both I and my wife.

It doesn't bother me to use the command line or to write an executable script that is linked to an icon, I just wish I didn't have to do this for every new release of Ubuntu to get around this issue in Nautilus.

Did the permissions function work in nautilus on earlier versions of Ubuntu? Did it ever work? If so, what broke it originally? Whats keeping it broken now? Just curious.

Here is a easy work around for those who don't use command line http://ubuntuforums.org/showthread.php?p=10012703#post10012703

I can confirm this bug in Lucid. I created a public family account and I moved a folder with with folders of images to the Pictures folder of the family account. I added the family group and changed the owner and group to family in Nautilus clicked the recursive "caontaining items" or whatever and nothing. I did it under root and under gksudo nautilus. I wound up doing it in the terminal which can cause mistakes resulting in re-installation.

Affects again nautilus on Ubuntu13.04 64bit raring

ApportVersion: 2.7-0ubuntu2
Architecture: amd64
DistroRelease: Ubuntu 13.04
GsettingsChanges:
 org.gnome.nautilus.window-state geometry '910x674+65+65'
 org.gnome.nautilus.window-state maximized true
 org.gnome.nautilus.window-state sidebar-width 283
InstallationDate: Installed on 2012-07-22 (153 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120722)
MarkForUpload: True
Package: nautilus 1:3.6.3-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.7.0-7.15-generic 3.7.0
Tags: raring running-unity
Uname: Linux 3.7.0-7-generic x86_64
UpgradeStatus: Upgraded to raring on 2012-11-15 (37 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo vboxusers

apport information

apport information

Still going on in 12.04. I copy a directory and change the permissions from root to me and set it as recursive but none of the files in directory are changed or even can be changed individually even using sudo. Happens mostly when copying directories from an external drive.

The same bug is in Ubuntu 14.04. When try to change Others to Read/Write permissions switch back to Acces files