Files issueshttps://gitlab.gnome.org/GNOME/nautilus/-/issues2024-02-09T19:58:37Zhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/1534Can't change file owner under admin:///2024-02-09T19:58:37ZAntónio Fernandesantoniof@gnome.orgCan't change file owner under admin:///# Affected version
- Nightly flatpak: Yes
- 3.36 stable.
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Use <kbd>Ctrl</kbd><kbd>L</kbd>
2. Type `admin:///tmp` and return. (It will as...# Affected version
- Nightly flatpak: Yes
- 3.36 stable.
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Use <kbd>Ctrl</kbd><kbd>L</kbd>
2. Type `admin:///tmp` and return. (It will ask for password)
3. Open the properties of a file or folder and go to Permissions tab
# Current behavior
The owner's name is a label, cannot be changed.
# Expected behavior
Since we are using the admin: backend, we should have enough privileges to change the owner.
# Additional information
This was noticed by me and @apoos-maximus while porting the .ui files to GtkBuilder UI definitions.
It will be fixed as part of the project.GNOME 3.38APOORV SACHANAPOORV SACHANhttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3125Cannot change group of all files while in admin mode2023-12-12T22:48:10ZAntónio Fernandesantoniof@gnome.orgCannot change group of all files while in admin mode<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see http...<!--
Please test if the issue has already been fixed in the Nightly version.
You can install the Nightly version in parallel with the regular version with these instructions:
1. Make sure that Flatpak is installed (see https://flatpak.org/setup )
2. Copy and run the following command in a Terminal:
flatpak install --from https://nightly.gnome.org/repo/appstream/org.gnome.NautilusDevel.flatpakref
3) The Nightly version can now be launched from Activities, or with this command: flatpak run org.gnome.NautilusDevel
-->
# Affected version
- Nightly flatpak: Yes
- Other: 45 (with latest bugfixes), and all earlier versions as well
# Steps to reproduce
<!--
Explain in detail the steps on how the issue can be reproduced.
-->
1. Run `nautilus admin:`
2. Open the Properties of a file owned by root.
3. Open the Permissions subpage.
# Expected behavior
<!-- Describe the expected behavior. -->
As admin, I can change the owner and group of any file or folder.
# Current behavior
<!-- Describe the current behavior. -->
While owner can be changed, group cannot.
# Additional information
The logic for changing groups predates the admin backend. Back then nautilus as root was apparently supported, so the code is still tailored for that use (which is unsafe and no longer supported).
<!-- Ignore the text under this line. -->António Fernandesantoniof@gnome.orgAntónio Fernandesantoniof@gnome.orghttps://gitlab.gnome.org/GNOME/nautilus/-/issues/3111Seg fault when clicking on 'properties' of any folder when running as super user2023-11-25T17:10:17ZfulalasSeg fault when clicking on 'properties' of any folder when running as super userTested on the following 64bit distros: Fedora 39 beta, Ubuntu 23.10 beta and PorteuX 0.7rc (which comes with GNOME 45 **final release**).
Steps to replicate:
1. `sudo nautilus`
2. right click on a folder
3. click on 'Properties'
This ...Tested on the following 64bit distros: Fedora 39 beta, Ubuntu 23.10 beta and PorteuX 0.7rc (which comes with GNOME 45 **final release**).
Steps to replicate:
1. `sudo nautilus`
2. right click on a folder
3. click on 'Properties'
This doesn't happen on 44.2 and below. I haven't tested on 44.3+.
Please, let's **not** discuss the matter of why running nautilus with sudo -- hold your _knowledge_ on this particular matter for yourself because the issue here is more important. :)https://gitlab.gnome.org/GNOME/nautilus/-/issues/1360Authentication dialog to open /root/ fails a second time after being canceled...2023-09-08T22:30:42ZHussam Al-TayebAuthentication dialog to open /root/ fails a second time after being canceled the first time.I'm not sure what a good title for this is but here is how to reproduce.
1) nautilus -q
2) Open nautilus (gnome-3-34 or master branch).
3) navigate to /.
4) Double click on /root folder. Gnome-shell shows an authentication dialog.
5) Cli...I'm not sure what a good title for this is but here is how to reproduce.
1) nautilus -q
2) Open nautilus (gnome-3-34 or master branch).
3) navigate to /.
4) Double click on /root folder. Gnome-shell shows an authentication dialog.
5) Click cancel on the authentication dialog.
6) Double click on the /root folder again.
7) Nothing happens.https://gitlab.gnome.org/GNOME/nautilus/-/issues/614Admin:/// toggle and indicator.2019-10-06T22:57:15ZGhost UserAdmin:/// toggle and indicator.### Use cases
Make it easier to access/leave the admin:/// interface
### Desired behavior
Put a toggle button in the hamburger menu to access admin:///. If admin:/// is being used, place an indicator in the address bar.
### Benefits o...### Use cases
Make it easier to access/leave the admin:/// interface
### Desired behavior
Put a toggle button in the hamburger menu to access admin:///. If admin:/// is being used, place an indicator in the address bar.
### Benefits of the solution
Provides visual feedback. Makes it easier to access/leave admin:///
### Possible drawbacks
None.
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/nautilus/-/issues/613files copied over to root folder should be owned by root.2018-09-23T15:05:02ZGhost Userfiles copied over to root folder should be owned by root.### Use cases
Transfer files from home folder to root folder.
### Desired behavior
The transferred files should match the permissions of the destination, as is the default behavior of `sudo cp`. Currently, if you copy files to root us...### Use cases
Transfer files from home folder to root folder.
### Desired behavior
The transferred files should match the permissions of the destination, as is the default behavior of `sudo cp`. Currently, if you copy files to root using the admin:/// interface, you get files in the root folder that are owned by the user. They should be owned by root.
### Benefits of the solution
Expected default behavior.
### Possible drawbacks
None.https://gitlab.gnome.org/GNOME/nautilus/-/issues/446SUDO Nautilus Ubuntu 18.04 LTS2018-05-18T00:53:16ZGhost UserSUDO Nautilus Ubuntu 18.04 LTS# Steps to reproduce
1. Open Nautilus.
2. Click Files pulldown / menu
3. Witness it work
4. Open terminal
5. sudo nautilus
6. witness it broken
Reproducible in: Ubuntu 18.4 LTS
# Current behavior
As per the steps to reproduce - eleva...# Steps to reproduce
1. Open Nautilus.
2. Click Files pulldown / menu
3. Witness it work
4. Open terminal
5. sudo nautilus
6. witness it broken
Reproducible in: Ubuntu 18.4 LTS
# Current behavior
As per the steps to reproduce - elevated nautilus has a broken menu
# Expected behavior
elevated nautilus menu works as user instance
<!-- Ignore the text under this line. -->https://gitlab.gnome.org/GNOME/nautilus/-/issues/433Better icon labels to show permissions in admin state2019-06-09T15:42:15ZGhost UserBetter icon labels to show permissions in admin stateCurrently, files and directories to which you don't have access are marked with an "X" label (or are they? I am hnestly not sure what the "X" symbolizes here):
![before_admin](/uploads/e1175a024e72cd2bf3b16d0b5d30204e/before_admin.png)
...Currently, files and directories to which you don't have access are marked with an "X" label (or are they? I am hnestly not sure what the "X" symbolizes here):
![before_admin](/uploads/e1175a024e72cd2bf3b16d0b5d30204e/before_admin.png)
After entering admin mode (using `admin:/path/to/things`) the icon labels still show the "X", but also a "lock" symbol:
![after_admin](/uploads/959238645c07bbf18961de52d61eca93/after_admin.png)
I find this a bit confusing, and instead suggest the following:
1. Without proper permissions, show files with a "locked lock"
2. After granted permissions, replace with an "unlocked lock" to show that the file is protected, but we now have access.