"Apply Permissions to Enclosed Files" button doesn't work

[Atalanttore]

 * Nemo version (nemo --version) 5.2.4
 * Distribution - (Mint 17.2, Arch, Fedora 25, etc...) Linux Mint 2.3
 * 64 bit

Issue
The changed owner and group of a folder are not applied to the files it encloses when you click the Apply Permissions to Enclosed Files button.

Steps to reproduce

1. Open Nemo with root privileges.
2. Select a folder.
3. Open its context menu.
4. Click on Permissions tab.
5. Change the Owner and the Group from one user to another.
6. Click on the Apply Permissions to Enclosed Files button below.

Expected behaviour
All enclosed files (and maybe folders?) belong to the new owner and group.

Actual behaviour
All enclosed files and folders still belong to the old owner and group. Clicking the Apply Permissions to Enclosed Files button did not change the permissions.

[Jeremy7701]

Expected behaviour
All enclosed files (and maybe folders?) belong to the new owner and group.

Owner and Group are not permissions.

If the "Apply Permissions to Enclosed Files" worked properly, it would only adjust the Read, Write, Execution flags.

Investigate the CLI command chown, which can do what you want - but care is needed if the recursive form is used.

[Atalanttore]

Investigate the CLI command chown, which can do what you want - but care is needed if the recursive form is used.

Hopefully, this is not the only option. I never need CLI commands on Windows 10 in everyday workplace use, and privately with Linux Mint it should be no different, please.

[Jeremy7701]

Changing ownerships is not "everyday workplace use".

How did these folders etc come to be owned by the wrong user?

[smurphos]

Whilst is always nice when the OS works as expected, when it doesn't make it work...this adds a 'Take Ownership' context menu option to nemo when the selection includes items not owned by the user. 4 text files.....

'Take Ownership' nemo action.

~/.local/share/nemo/actions/take_ownership.nemo_action

[Nemo Action]
Name=Take Ownership (Admin)
Comment=Take ownership of %F
Exec=<action_scripts/take_ownership.sh %F>
Icon-Name=system-users-symbolic
Selection=notnone
Extensions=any;
Conditions=exec <action_scripts/check_ownership.sh %F>;
Quote=double
Dependencies=zenity;

~/.local/share/nemo/actions/action_scripts/take_ownership.sh

#!/bin/bash
export SUDO_ASKPASS="$HOME/.local/share/nemo/actions/action_scripts/zenity_askpass.sh"
SUCCESSSTRING="Ownership changed to $USER:$USER -"
COMMAND="sudo -A chown"
for i in "$@"; do
  if [ "$(stat -c %U "$i")" = "$USER" ] ; then
    continue
  fi
  if [ -d "$i" ]; then
    if zenity --question --icon-name=dialog-question --no-wrap --title="Take ownership" --text="Take ownership of directories recursively?"; then
    COMMAND="sudo -A chown -R"
    fi
    break
  fi
done
 for i in "$@"; do
  if stat -c %U "$i" | grep "$USER"; then
    continue
  fi
  eval "$COMMAND $USER:$USER '$i'"
  if [ $? = 1 ]; then
    zenity --info --width=250 --text="Error taking ownership of $i. Try again."
    exit 1
  else
    SUCCESSSTRING+="
    $i"
  fi
done
notify-send "$SUCCESSSTRING"

~/.local/share/nemo/actions/action_scripts/check_ownership.sh

#!/bin/bash
for i in "$@"; do
  if [ "$(stat -c %U "$i")" = "$USER" ] ; then
    RESULT="1"
    continue
  else
    RESULT="0"
    break
  fi
done
exit "$RESULT"

~/.local/share/nemo/actions/action_scripts/zenity_askpass.sh

#!/bin/bash
zenity --password --title="Authenticate"

[Jeremy7701]

@smurphos That is very impressive!

A possible problem -- $USER needs to have a sudoers entry...
Also, the group is set to the same value as $USER - but that could be easily fixed (if desired).

[Atalanttore]

Changing ownerships is not "everyday workplace use".

How did these folders etc come to be owned by the wrong user?

The files and folders were created by one user for another user (with a different user account).

[smurphos]

I use it for much the same use case as Atalanttore - files in a 'data' partition shared with multiple users - all users are members of each others groups, but files do end up being owned by the user who (last) saved or created them, and this does complicate
some things (backup primarily) so I just wanted a quick GUI way to take directories and files under my user and groups ownership. And a user who is not a sudoer should definitely not be able to take ownership of any file....

[LinuxOnTheDesktop]

I am left unclear about what Nemo's permissions window is supposed to do; and it still, on Mint 21, cannot do something that I wish it to do - though I think it gives the false impression that it can - namely, set permissions to items within a selected directory.

[taltamir]

whether or not changing owner and group is a standard daily occurance or not, the gui explicitly states it does a thing, and then does not do the thing it tells you it does. which is a bug.

also, this bug is wider in scope than what the original post stated.
this is not limited to changing owner and group. any and all changes in permissions do nothing when you click on apply permissions to enclosed files button.

currently as of 21.3 opening nemo ordinarily as a user (without admin permissions) nemo does not allow me to change owner (as in, there is no drop down menu for it).
however nemo does allow me to change:

1. group
2. read/write/execute flags for files and folders for owner, group, and others.
3. special flags "set user ID" "set group ID" and "sticky"

I just tested changing every single allowed property.
when using nemo to modify permissions on an individual file. everything works.
when clicking on "apply permissions to enclosed files". nothing works. that button is simply nonfunctional

[Jeremy7701]

If a user could change a file/folder to some other user owner there would be no point in having a permissions system.
This is why only root (or admin in the GUI) can change the owner.
So not a bug - its an important feature.

The apply "permissions to enclosed files" is actually quite complicated.
Assuming it worked:-
You obviously won't be able to escalate the permissions of a file, unless you own it - so the operation might fail for some files.
Is "apply permissions to enclosed files" meant to replace existing permissions or be an additive operation?
Do you really want all files in a directory to have exactly the same permissions?

Since it's such an indefinite thing, you might be better served by chmod in the CLI.

[LinuxOnTheDesktop]

@Jeremy7701 : it seems to me that the fundamental point made by taltamir can be rendered as the following deduction.

1. The window at issue offers to do something that it does not. (Premiss.)
2. If a window offers to do something that it does not do, then that is a bug. (Premiss.)
3. The window at issue is buggy. (Inference from 1, 2.)

The deduction is valid. That is, it contains no inference that contravenes the laws of logic. So if one rejects the argument (thinks the argument valid but unsound) then one must show one or more of the premisses to be false. Yet, both 1 and 2 seem true.

[Jeremy7701]

There are two issues:-

1. (Not a bug) nemo does not allow a user to change the owner of a file or directory, unless you are a root or admin user.
2. The offer to apply "permissions to enclosed files" for a directory is a bug since it does nothing - even if you are a root user.

[Atalanttore]

I am amazed and at the same time shocked that the laws of logic have to be used to justify the problem of a GUI that is misleading for the user.

[taltamir]

If a user could change a file/folder to some other user owner there would be no point in having a permissions system. This is why only root (or admin in the GUI) can change the owner. So not a bug - its an important feature.
(Not a bug) nemo does not allow a user to change the owner of a file or directory, unless you are a root or admin user.

@Jeremy7701 you are misreading what people are saying. Nobody is asking for this.
please reread my post.
I never suggested that the goal is to have nemo ignore/bypass permission restrictions.

Nemo correctly uses chown and chmod on one file at a time.
It fails to perform those exact same commands with -R option. this is this bug.
this has nothing to do with requesting it to ignore permissions.

Some argued this is intentional. I counter argued that if it is intentional for -R to be disabled in the GUI, then the GUI should not give you that option.
Again, this does not in any way shape or form request nemo to bypass permission requirements.

My personal guess is that this bug is caused by nemo is trying to use -r instead of -R when using the recursive button.

I also tested it out and it respects permissions. saying you are forbidden to change files you do not own, and changing files you own. so long as you change one file at the time and thus avoid the -R bug.