Wastebasket fails with read only directories

A corresponding upstream bug report:
http://bugzilla.gnome.org/show_bug.cgi?id=108307

*** Bug 10257 has been marked as a duplicate of this bug. ***

upstream bug is still open, but I cannot reproduce this bug on dapper. perhaps
it was fixed and upstream forgot to close the bug?

*** Bug 26600 has been marked as a duplicate of this bug. ***

Changing the status to confirmed for the ubuntu portion of the bug, (to remove it from the untriaged bug-list)

I like to confirm this, since files moved from a CD to the Wastebasket have
a read-only attribute and cannot be emptied easily.

On 8/15/06, Bug Watch Updater <email address hidden> wrote:
>
> ** Changed in: nautilus (upstream)
> Status: Unknown => Confirmed
>
> --
> Wastebasket fails with read only directories
> https://launchpad.net/bugs/7560
>

This is actually the same as bug #39482 and they need to be merged. The root of the two observed behaviors is the same. I have sent a patch upstream but it was argued that it might incur too much overhead and was thus rejected. This thread shows what type of a patch Alex (nautilus upstream) would be willing to accept - http://<email address hidden>/msg02853.html (for the interested make sure you follow the complete thread). I had intentions to work on this, but currently lacking some time and need to attend to other stuff. Upstream would welcome something along the lines he's described.

hmm, this dosn't sound like a 'bug' to me, more like a wishlist.

I think nautilus is behaving fine, the whole point of read-only is that the files permissions are rigged to not allow you to edit the files / delete them.

As nautilus's abilities are based upon your user privilages. Nautilus cant edit the files / delete them either.

Again. I really think this should be wishlist

> I think nautilus is behaving fine, the whole point of read-only is that the files permissions are rigged to not allow you to edit the files / delete them.
Well then it shouldn't move them to the trash in the first place.

Probably my problem is the same as yours, lets see: I copied files from a SMB server to my local desktop. The original files have read-only permissions and so have the copies on my desktop. The result is that I can not modify or delete the files on my desktop anymore. Very silly bug!

This is not a bug. Readonly files that the user owns are deleted normally. If you don't own the file you can't delete it unless the permissions allow it.

Sorry, yes read only directorys cannot be removed even by the owner. I will look into altering that dialog. I think something like "This directory is marked as readonly, are you sure you want to remove it?" would be more appropriate than the current "You do not have permission" error esp. since it occoures even if you DO have permission to alter the permissions. If I get something useful I will link a patch and send one upstream for them to look at.

Why is it not a bug as I described on 2007-05-07? That an ordinary user can create files but not delete them should not be conform with the motto "it just works". Instead it reminds me of a kind of DRM...

Well really its just that gnome-vfs/nautilus is just informing you that the permissions are set so that you can't delete said directory and not offering to change them for you so they can be deleted. This is only an issue with directories and not files (I am not sure why). File permissions exist for many reasons and security just one of them. Strict permission control is one of the things that makes Linux so secure.

I agree with the previous comments that this is not a bug. However, it should be considered to process the files being moved to the Trash to see if the user has permissions to delete them, and throw an error if the permissions do not allow it. But that could get complicated.

Confirmed in gutsy.
My recommended fix is that when you choose to empty the trash, nautilus should do either this:
if [ `rm -fr ~/.Trash/*` != "" ]
then
chmod +w ~/.Trash/
if [ `rm -fr ~/.Trash/*` != "" ]
then
#Do the "This file could not be deleted" thing
fi
fi

Or:
chmod +w ~/.Trash/
if [ `rm -fr ~/.Trash/*` != "" ]
then
#Do the "This file could not be deleted" thing
fi

The former would be faster if most files are writable (probably the case), but the latter would be would be faster if most of the files are not writable.

This is a bug, and I can also confirm it.

If you're not supposed to have write permission, why can you move it to the trash in the first place?

This is still an issue in hardy.

I marked bug 3868 and its duplicates as duplicates of this bug. They both referenced the same Gnome bug, but this one contains more detailed information on how to duplicate the bug.

Hardy 8.04
Nautilus 2.22.1

I had a directory that I owned moved to Trash.
The directory contained files and directories owned by root but I was not challenged.

The rules for moving to Trash need to use inbuilt security.
The files that are actually in Trash need to be fully under control of the owner of the Trash directory.
i.e. move to trash is really 'chmod -R', to take ownership of the moving files and then 'mv'.

Although the status of this bug is 'confirmed' I can't see what is to happen next.
Is there a fix in the pipeline?

Same on Hardy Beta as Peter T H. said above.

Also once a folder with root owned items is put into the trash, not only you cannot delete it but you cannot drag it back out of the trash without a permission denied error. This is not a Wish List, it's quite serious.

I'm on Hardy Beta.
I got a similar issue when I installed "True Combat: Elite" and then tried to delete it. I can't replicate it though.
The folder in my Trash is ".etwolf" the folder with root ownership is on ".etwolf/tcetest/zzz_sr8-r93_nopistol.pk3". Trying to delete ".etwolf" spits back the error: "Error removing file: Permission denied".

I've got no clue how to delete this folder, nor fix this issue. This is not a wish list.

another thing is that -since hardy- ~/.Trash is gone, one cannot run 'sudo rm -rf .Trash/*' anymore.
how do i actually delete those files and folders in wastebasket?

rm $XDG_DATA_HOME/Trash/*
normally $XDG_DATA_HOME is ~/.local/share/, so
rm ~/.local/share/Trash/* is the equivalent command.

thanks, that did it!

When I visit ~/.local/share/Trash/ the files I want to delete don't appear to be there.

rm ~/.local/share/Trash/* results in an error because there are directories contained in that folder...

Actual files are stored in that $XDG_DATA_HOME/Trash/files/, but every file in that folder has a corresponding entry in $XDG_DATA_HOME/Trash/info/ that needs to be deleted as well (else you get "phantom files", they show up in trash but nowhere else). Also, external mounts store trash (mount-root)/.Trash(-$UID)/ following the same specification. Usually just removing everything in those directories is enough to fix "hung files."

When I had this problem in in Ubuntu 8.04 (Hardy Heron), the following worked for me:

1. Go to .local/share/Trash/files in your ´home´ directory, for example on the command line:
     cd .local/share/Trash/files
2. Type in: sudo rm -r name_of_folder

Maybe it is best to check folder and file permissions before trying to send stuff to the wastebasket? The security in Linux also makes for a bit more work. Worth it though!

I was trying to get rid of an old edition of the Eclipse IDE. It just didn´t want to budge!

type "sudo chown -R {insert user name here} ~/.local/share/Trash/*" into the terminal

This will change the owner of all files in the trash to you then just empty the trash like normal

Ubuntu Hardy

I was seeing this too. Using chown to reassign the files to me worked fine.

In my own cack-handed attempt to remove files in my wastebasket owned by root, I started a 'sudo nautilus' session and clicked on 'Deleted Items' in the sidebar. The window grayed out and did not come back. It appeared to leak memory, taking up 2GB once a minute or so had passed. Something had gone seriously wrong!

At least 'Force Quit' worked on the window, and the memory was released. Perhaps another bug should be raised for this behaviour?

Ubuntu Hardy.

@ Patrick Byrne
Doing something similar to you I ended up with a greyed out gksudo nautilus as well which kept taking up memory until I forced it to close.

In my opinion it shouldn't be necessary to resort to to the terminal to delete files.

I can confirm this bug. Simply run 'gksu nautilus' and select Trash from the sidebar is enough to trigger this memory behaviour.

the sudo issue is an another bug

Hi there,

I also have that problem, and I want to add another perspective. I have put 2 folders in my wastebin, a small on: firefox 10,6 MB and a larger one: APTonCD 928 MB. I had previously changed the permissions: '$ sudo chmod -cR 777 ./firefox* ./APTonCD' and '$ sudo chown -cR 1000 ./firefox* ./APTonCD'. Because of failure to: '$ sudo install ./firefox* /bin' and failure to attach the APTonCD packages to apt-cache. When I removed them to the wastebin I could not permanently delete nor restore them, nor write them away to a backup device. Now as a newbie I don't know where my wastebin is located or what it is called (trashapplet? gnometrash?). I see the wastebin icon on my lower Desktop panel, in the right below corner. When I do '$ cd /home/user/Desktop' and '~/Desktop$ ls -la | less' I find no reference to the wastebin. I also don't know how to use the grep command. Is it '$ sudo grep 'wastebin' ./*' or something like that? My normal method to find the path to those files is to right click on their icons in the GUI and click on propertis. Unfortunately in my wastebin all icon paths are displayed as: trash:///. Even more unfortunate:

thomas@thomas-laptop:~/Desktop$ cd /trash
bash: cd: /trash: No such file or directory
thomas@thomas-laptop:~/Desktop$ cd ~/trash
bash: cd: /home/thomas/trash: No such file or directory
thomas@thomas-laptop:~/Desktop$ cd ./trash
bash: cd: ./trash: No such file or directory
thomas@thomas-laptop:~/Desktop$

Therefor I cannot resore permissions on these files. So that is already 1 GB that is there forever. The only way to fix this problem with the very poor Linux skills I have, that I can think of anyway, is to backup everything and reformat the partition. Now when I download a large .torrent file, I get the error message: 'this torrent is paused, not enough disk space is available'. So this problem may be more serious than it seems for many novice users. Maybe you compu wizards can write a HOWTO for newbies?

I have equal experience of Daniel Silverstone in the Ubuntu 8.04 distribution:

an directory with read-only permission can moved in the trash but can't removed from the trash.

Then i have execute "sudo chmod -R +w .local/share/trash/files/*" from my home

At this point the trash can be emptied.

i think that nautilus must change the permission to write mode of all objects trashed and annotate the original permission in the object's info files in ~home/.local/share/Trash/info/ directory and reassign original permission when a trashed object are "un-trushed" with an appropriate button that do not exist for now.

excuse me my english.

Fully agree with previous commenter.
What about situation in Intrepid? Nautilus can restore files from trash there, what about permissions?

Confirming in Intrepid,

This fixed it:

root@thomas-laptop:/home/thomas# chmod -R +w ./.local/share/Trash/files/*
root@thomas-laptop:/home/thomas# rm ./.local/share/Trash/files/*
rm: cannot remove `./.local/share/Trash/files/allvarlogs': Is a directory
root@thomas-laptop:/home/thomas# rm -R ./.local/share/Trash/files/*
root@thomas-laptop:/home/thomas#

Fix for this was committed upstream in GVFS:
2008-12-16 Ryan Lortie
        * daemon/trashlib/trashexpunge.c: set files to mode 700 before
        deleting to deal with users trashing read-only directories

This bug was fixed in the package gvfs - 1.1.3-0ubuntu1

---------------
gvfs (1.1.3-0ubuntu1) jaunty; urgency=low

  * New upstream version:
    - ftp: fix limited number of connections causes commands to fail
    - trash: fix parallel build doesn't work
    - trash: add trash::orig-path and trash::deletion-date info
    - trash: set files to mode 700 before deleting to deal with users trashing
      read-only directories
    - smb-browse: browsing authentication support (lp: #193232, #207072)
    - smb-browse: make backend not automounted anymore
    - New trash backend (lp: #7560, #187565, #201393, #206747, #207835, #216739)
    - Use the new shadow mount facility in gio
    - gphoto2: Use shadow mounts
    - obex: Fix icon for root directory
    - http: Fix major memory leak (lp: #225615)
    - http: Support proxies
  * debian/patches/01_maintainer_mode.patch,
    debian/patches/90_relibtoolize.patch:
    - commented debian change for now since it's not really required and create
      build issue using the jaunty libtool version
  * debian/patches/90_correct_glib_use.patch:
    - the issue is fixed in the new version

 -- Sebastien Bacher <email address hidden> Wed, 07 Jan 2009 22:52:11 +0100

as an 8.04 user I still have the problem. At least this thread told me where to find the trash. Nautilus is too clever at hiding things. Sometimes one NEEDS to know what is under the hood.

I disagree with the fix though. Files/folders that the user has no right to delete should never make it to the trash bin in the first place. In order for the user to be able to move a file to trash, they should ALREADY have the right to delete that file.

Also still on 8.04 and I agree with the comment above by Chris. Readonly dirs/files should not be moved to Trash.
And:
Files deleted on a nfs-dir are almost impossible to find because they reside on the nfs-dir itself in a .Trash-$userid file.

Don't reopen closed bugs, that issue is fixed since jaunty, you can nominate an hardy task if that's what you are trying to get solved but that doesn't qualify for a stable update