Ubuntu

"Cannot move file to trash, do you want to delete immediately?" on NTFS / VFAT partitions

Reported by Miguel Martinez on 2008-02-17
214
This bug affects 27 people
Affects Status Importance Assigned to Milestone
GLib
New
Medium
glib2.0 (Ubuntu)
Low
Ubuntu Desktop Bugs

Bug Description

Trying to delete files with nautilus from a vfat partition "fails". Well, the file can be deleted OK, but it seems gvfs can't send the file to the trashcan, so only permanent delete is available. Furthermore, the name of the file appears in little boxes, similar to viewing a chinese site using Latin-1 encoding (will attach screenshot).

Distro: Hardy up to date (17-february 2008)

Steps to reproduce: Copy a file to an vfat partition. Select it and delete using nautilus. A message error will appear:
  "Can't move file to trashcan. Do you want to delete it inmediately?"
  "File <<little-boxes>>cannot be moved to trashcan"

Versions:
Nautilus 1:2.21.91-0ubuntu2
gvfs 0.1.7-0ubuntu4

/etc/fstab for the vfat partition:
UUID=9445-A956 /fat32 vfat defaults,utf8,umask=007,gid=46 0 1

Miguel Martinez (el-quark) wrote :

Trashcan error in spanish (es_ES.UTF-8)

Sebastien Bacher (seb128) wrote :

Thank you for your bug report. Not having a trash there is the expected behaviour right now because the user doesn't own the exclusive permissions on the drive, do you think it's wrong, why? Don't specify hardy to the bug title, the information will be incorrect when hardy+1 opens and creates confusion and extra work, the bug should be closed if it's fixed in hardy and you can use the description

Changed in gvfs:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Incomplete

Dear Sebastien,

First of all, I felt it was wrong because deleting files to trashcan has been the default behaviour from Warty to Gutsy. You've got a point that I, as a user, don't have exclusive rights to that drive. Another point is that most vfat partitions mounted in ubuntu are probably USB flash memories, where a user might not want to leave residual files by default. In this case, however, this is a hard drive partition, using the default mount options from a Gutsy pre-release live CD. I expected files deleted on the local hard drive going to the trashcan.

Seeing that you hinted that default behaviour now is directly deleting files to which you don't have exclusive access, I've performed a couple of tests chowning miguel:users back and forth. The results were:
-A file inside $HOME goes to the trashcan as usual. It doesn't depend on the group owning the file.
-If we put the sample file in /home/$USER/wherever and chown -R $user:users ~/wherever the results are still the same
-If we have full access to a source directory (i.e. /usr/local/src/XCrySDen), we get similar behaviour to that seen in the vfat partition. This happens even if the file is owned by miguel:miguel and even if the directory containing the file is also owned by miguel:miguel.

So the bug seems to be more like "cannot send files lying outside of $HOME to trashcan". In any case, I'm no longer sure what is the correct behaviour. I feel that if you own `pwd` you should be able to send the file to the trashcan, although you have a good point on the plugdev mount.

Finally, thanks for the suggestions on bug titles.

PS: /fat32 is a partition in my laptop's HD used to share data between windows XP and linux. Even though ntfs-3g has made the partition somewhat redundant, I'd still rather have it.

Sebastien Bacher (seb128) wrote :

That's not the permission of the file you are deleting which matter but the ones from the trash directory. The issue when this directory is not owned by your user is that other users can see things you have deleted which can be a security issue. I've discussed the issue some time ago with Alexander which is gvfs and nautilus upstream and he wrote a mail to the xdg list, you might be interested to read it there, http://lists.freedesktop.org/archives/xdg/2008-February/009192.html

Sebastien Bacher (seb128) wrote :

Reassigning to glib for now, I opened http://bugzilla.gnome.org/show_bug.cgi?id=514697 about the topic some time ago

Changed in gvfs:
status: Incomplete → Triaged
Changed in glib:
status: Unknown → New
pt123 (pt123) wrote :

I was referred to this bug from this bug I reported
https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/207566

But looking at this referred bug, fat32 deletion works fine for me. It is just NTFS drives.

Rocko (rockorequin) wrote :

A workaround is to assign user permissions in the fstab entry for the partition, eg:

/dev/sda2 /c ntfs defaults,umask=007,uid=1000,gid=1000 0 1

So perhaps the Ubuntu installer should do this by default for detected ntfs-3g drives?

Or alternatively, perhaps Nautilus should tell you *why* it can't move the files to trash, and explain that if you mount the partition in the above way you'll be able to move files to trash?

Download full text (3.2 KiB)

thanks for the hint rocko, and thanks for the read sebastian bacher.
i know that we cant go around making the ntfs drive owned by the user, but changing the fstab line to something like:
/dev/sda2 /c ntfs defaults,umask=007,uid=1000,gid=1000 0 1
gives some useful results at least:
files are deleted with a single delete key, and appear in trash:// but havent been copied on to the other partition, but are rather stored in the folder .Trash-1000. (if the fstab line is changed back, files in .Trash-1000 do not appear in trash://), so it is all technologically possible

Security concerns dont really exist with trash folders on shared drives:
If you delete a file that was public on an ntfs drive, you expect it to go to your trash, and will expect it to still be public, and if you really want to get rid of it you will know you have to empty your trash. The problem set up in gutsy was where file were deleted and then vanished from the gui, but still existed on the hard drive, ie security worry as people thought it was gone, but it wasnt. As the files are now in the gui there is no problem any more. This is the expected behaviour.

If another user puts a file in your recycle bin maliciously, this can hardly be called a security concern either. The idea of potentially a malicious file appearing in your trash and you opening it is not really something to worry about. The exact same thing could happen in the drive itself, ie a user puts a malicious file in your reservered (ie by social convention) folder on the ntfs drive, and you wonder where it is from and open it. the fact that it is now the trash folder as well adds nothing.

if each user has a seperate .trash-{user} folder on the ntfs drives, the above concerns only exist if another user on the system goes out of their way to either read someone elses trashed files, or to put a file into someone elses trash folder. But as there is no concept of any security on this drive, this is already the case: a user can go out of their way read someone else's files, or to put something into someone else's reserved (ie by social convention) folder.
by putting an ntfs drive into your computer the users and admin have to accept that there is a potential security hole through this drive, and are relying on trust for your users, the trash is no different

all the technology is there now. the only worry is security concerns, but they are really moot. We cant help people who have ntfs drives, they know that security is weaker. They must accept that any files stored on that partition are going to be public untill they are completely removed (but now are not put under the false impression that they are gone), and also that any other user is free to put any file onto that drive, which you might bump into by accident.

i suggest using .trash-{user}, and having the contents of that folder appear in the relevant user trash:// folder. if the admin cares about security of files it will be obvious that no files should ever be stored on the ntfs drive (or get rid of the drive), if the admin lets the users store file on this drive, then it is clear that the admin is relying on trust between the users when dealing with files on...

Read more...

I have a similar problem (Bug #230105, sorry for the duplicate)

Now my etc/fstab contains as follows:
----
/dev/sda4 /data vfat defaults,utf8,umask=007,gid=46 0 1
----
While in etc/group:
-----
plugdev:x:46:haldaemon,mat,root
...
mat:x:1000:
----
(mat is me)

If I change the gid to 1000, what will happen to haldaemon? Will the system automount the partition in any case?

Anyway, trashing should work also with the gid=46 and implicit uid=0: infact if a file X is owned by user Y and is in a directory owned again by user Y BUT the permissions are such that an user Z can read & write access it, then Z should be able to delete the file X and the file should go to the Z user trash directory on the same partition.
I assumed that every user has an own trash directory in every partition on which he/she/it has write-access.
This is (I think) the case, so WHY doesn't it work?

aaron (nelaaro) wrote :

I have seen this bug in a few places and I have not found a simple solution to post in the Ubuntu forums. I am having. the same problem. I understand how to edit the fstab entries. But before I post a reply to this thread http://ubuntuforums.org/showthread.php?t=774426 in the Ubuntu forums, I would like to make sure that I have the fix correct and easy enough to follow for just about every body.

You need to determine the partition and device that contain the ntfs partition.
 #sudo fdisk -l
   Device Boot Start End Blocks Id System
/dev/sdb1 1 60801 488384001 7 HPFS/NTFS
You then need to open the fstab file in /etc/fstab and add and entry to mount the ntfs partition with the correct mount options to ensure that it is mounted as the correct user.
First create the directory to mount the ntfs partition to.
sudo mkdir /media/[myntfs_part]
#gksudo gedit /etc/fstab
then add the following lines to the fstab file.
/dev/sdb1 /media/[myntfs_part] ntfs defaults,umask=007,uid=1000,gid=1000 0 1

Is this the correct solution. I am not sure if I should use the /media directory or the /mnt directory. What is the standard. I see Rocko using /c.

I also feel that the user should always have the default option of sending data to the trash directory even if it is insecure. The average every day desktop user is not interested in performing all the above steps just to be able to have files got to a trash can. If it is a security risk the the user should be told this in the delete prompt as a warning. Only having a permanently delete option as has been stated will cause some frustration when people realise later that they can't get their files back.

If Ubuntu is designed as an average every day desktop system the security risk when heaving a multi-user work station would mean that it has already gone to beyond the average every day desktop system where in the majority of cases only a single person uses a computer. On a multi-user work station the user should be told that their files, when deleted and moved to trash will be available to other users on the system. Josh Smith and Rocko have made this point quite well.

2.6.24-17-generic #1 SMP i686 GNU/Linux
Ubuntu Hardy

Vancouverite (sethgilchrist) wrote :

This fix worked for me on a vfat partition, however it didn't work for anyone else using the computer.... I know it wasn't supposed to, but a fix that works on a multiuser system would be good. Now I can use the trash, but my girlfriend can't. For the safety (rather than security) of her files she has a separate log on.

I never had this problem in Gusty, was there a change for Hardy?

Thanks for finding at least some work around, all the work is much appreciated.

The current behaviour is just plain silly in my opinion. If the file system doesn't support 'proper' permissions that's none of our business. That's the file system I choose to use, I know it's limitations. It's all fine for the Linux world to try and solve this - but it's not a *nix problem. It's a windows one. I think it would be wrong to implement something which makes users feel that VFAT has something that it doesn't.

I dual boot and my home folder is in another partition, I am the only one using this computer. Not having the files go to the trash is actually REALLY BAD for me. Even when I decide to delete windows I will still keep all files in the other partition for easier upgrades in the system. Please fix this bug.

I totally agree with aaron.
"If it is a security risk the the user should be told this in the delete prompt as a warning. Only having a permanently delete option as has been stated will cause some frustration when people realise later that they can't get their files back."

Luke12 (luca-venturini) wrote :

There is a hackish solution for this, without having to go into the fstab, at least in Intrepid. THIS ONLY WORKS WITH INTERNAL NTFS DRIVES.

First, mount the ntfs drive by clicking it in Nautilus. Once you've done this, go to computer:/// in nautilus, right click on the drive, and go into the "drive" section, mount settings. There, on the mount options, add "uid=1000" without commas. Unmount and remount using nautilus. If you get errors the first time, just use dolphin to mount cleanly, unmount, second time it should work like a charm.

And yeah, nautilus at this is far worse than dolphin. Rant: another thing which makes me wanting to switch to KDE4 for good, ASAP.

This bug is related to #268152.

In this other bug, you cannot delete your images if they are located in a NTFS partition. And, what's even worse: you don't have the option to erase directly (like pressing Shift-Del).

YannUbuntu (yannubuntu) wrote :

I still have this bug in Intrepid. I use a NTFS partition for all my data (pictures, documents, songs) in order to use them both with XP and Ubuntu.

This bug is really painful for new Ubuntu users: it prevents from deleting songs in Rhythmbox, pictures in EOG, files in Nautilus...
Please warn the user with a simple message (and why not a security option to choose in the "Administration" menu), but DON'T make his first Ubuntu experience a PAIN !

YannUbuntu (yannubuntu) wrote :

I confirm the solution found by the French team:
edit the /etc/fstab file, and change:
UUID=XXXgrand chiffre XXX /media/Documents ntfs defaults,umask=007,gid=46 0 1
in
UUID=XXXgrand chiffre XXX /media/Documents ntfs defaults,umask=007,uid=1000,gid=46 0 1

Then reboot and the Trash works again for your NTFS partition !

Rocko (rockorequin) wrote :

You can also specify these options for an external USB drive or partition: Open Places / Computer and select Properties for the partition (volume) in question. Then on the Drive or Volume tab you can specify the options you want in the Mount Options text box, eg "umask=000,uid=1000". Once you unmount and remount the partition, trash starts working correctly.

I still think these should be the default mount options for external NTFS drives. After all, that's how windoze treats them, and consequently nobody expects an NTFS drive to be secure.

Adding uid=1000 will only solve the issue for the first account created, by default given user id of 1000. So how can the same approach be made to work for all users?

That is exactly what I say!

The solution is SO SIMPLE: O.S. should ONLY WARN the user of security
risks thrashing on NTFS, but NON avoid it. As it was just a year ago.
I'm saying this for months.

This is treating users like stupids as a nanny, as windows does. I just
hate it! I came to linux just because I hate it, and now linux is
transforming into windows! Argh!

Duncan Lithgow ha scritto:
> Adding uid=1000 will only solve the issue for the first account created,
> by default given user id of 1000. So how can the same approach be made
> to work for all users?
>
>

YannUbuntu (yannubuntu) wrote :

I agree with Rocko ("these should be the default mount options") and Mat ("ONLY WARN the user of security risks thrashing on NTFS, but NON avoid it.").

Even if this solves the issue only for the first account created (I didn't check for other accounts), I think it's much BETTER than the current situation!

I agree with the two previous comments. NTFS is a Microsoft creation,
Linux should not try and treat it 'better' than windows does - this is
not Linux's problem. For the same reason FAT volumes are no longer
checked every time, if windows doesn't do it neither should Linux.

YannUbuntu (yannubuntu) wrote :

no decision taken for this bug? someone working on it?
i see no activity on http://bugzilla.gnome.org/show_bug.cgi?id=514697 :-(

i think "importance" should be increased: this bug is a pain for new Linux users (who generally use a Win/Linux dualboot for a soft transition, with FAT or NTFS partition for Win/Linux doc exchange), as it prevents from deleting songs in Rhythmbox, pictures in EOG, files in Nautilus...

Please warn them of the security problem (with an option for more security if you want) but don't make their "transition to Linux" a pain!

One more point: as far as i remember, there wasn't this bug in Gutsy. Can someone confirm?

Kmassada (kmassada-gmail) wrote :

So did any one really find a solution, the solution of the french team crashed my ubunutu on another machine. I always try things on that test machine before doing it on my laptop. my uid is 1001, may be that was the problem, not too sure.... after that it won't even let me edit the fstab anymore... anyways, its just a test machine, so i just did fresh install on that one.

UUID=XXXgrand chiffre XXX /media/Documents ntfs defaults,umask=007,gid=46 0 1
in
UUID=XXXgrand chiffre XXX /media/Documents ntfs defaults,umask=007,uid=1000,gid=46 0 1

I use NTFS config to mount my drives, here's my fstab file

# /etc/fstab: static file system information.
#
# -- This file has been automaticly generated by ntfs-config --
#
# <file system> <mount point> <type> <options> <dump> <pass>

proc /proc proc defaults 0 0

# Entry for /dev/sda5 :
UUID=63b5b045-05f1-4968-a305-a9017c33b28a / ext3 relatime,errors=remount-ro 0 1

# Entry for /dev/sda6 :
UUID=46d99e69-024e-41e5-b78d-02c0f2310e5d none swap sw 0 0
/dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0

/dev/sda2 /media/HP_RECOVERY ntfs-3g defaults,locale=en_US.UTF-8 0 0

/dev/sda1 /media/MainDisk ntfs-3g defaults,locale=en_US.UTF-8 0 0

I also read about some patch on some website, but have been looking around and no one seem to really come up with an understandable guide on how to do it...

btw, i read someone say he's trying to switch to KDE, I am coming from Kubuntu, and its really much better than ubuntu, the only reason i stick with ubunutu, is because of the speed. Kubunut is Bloody slow... pls don't tell me its my computer, i make it fly with windows, why won't kubuntu do it, ubuntu did???

godmarck (godmarck) wrote :

Hi, I'm pretty new to Ubuntu/Linux, but I think I'm pretty much getting the idea of all this,I've already made my transition from windoze to Linux and I'm pretty sure I'm not going back to the windoze pain.
I got my solution by adding to my fstab the "uid=1000" part, now I can happily trash files.
But I just don't get something, this "uid=1000" is like an option or something??
I know UID means User ID (probably) and that the "1000" is the first user's ID number...
But what does it exactly do? look at my fstab
/dev/sda4 /media/sda4 ntfs-3g rw,user=godmarck,uid=1000,defaults,locale=en_US.UTF-8 0 0

Wasn't that part covered by the "user=godmarck" already? or that is to allow me to rw??
I'm pretty sure I've got some things there that are not needed at all.
I'm not sure if this is the place to ask about this, but I'd appreciate any help.

That uid=1000 means "this partition is propriety of the first user.
So, if you have two users, the first one can surely trash, the second...
in some cases can't!
This is idiot.
The partition should be propriety of super-user, and trash should be
possible for all users.
I've been repeating this for a year.

godmarck ha scritto:
> Hi, I'm pretty new to Ubuntu/Linux, but I think I'm pretty much getting the idea of all this,I've already made my transition from windoze to Linux and I'm pretty sure I'm not going back to the windoze pain.
> I got my solution by adding to my fstab the "uid=1000" part, now I can happily trash files.
> But I just don't get something, this "uid=1000" is like an option or something??
> I know UID means User ID (probably) and that the "1000" is the first user's ID number...
> But what does it exactly do? look at my fstab
> /dev/sda4 /media/sda4 ntfs-3g rw,user=godmarck,uid=1000,defaults,locale=en_US.UTF-8 0 0
>
> Wasn't that part covered by the "user=godmarck" already? or that is to allow me to rw??
> I'm pretty sure I've got some things there that are not needed at all.
> I'm not sure if this is the place to ask about this, but I'd appreciate any help.
>
>

YannUbuntu (yannubuntu) wrote :

Thank you Mat for your explaination.

I am worried because I see no answer from people who could fix this, or know where to fix it.
Is this bug correctly assigned to "Gnome Bugs" ?

touristguy87 (touristguy87) wrote :

"I still think these should be the default mount options for external NTFS drives. After all, that's how windoze treats them, and consequently nobody expects an NTFS drive to be secure."

LOL!

Come on people!!!!

Don't turn this into a Windows vs Linux battle.
Just fix the damm bug.

The volume format shouldn't matter.
You start changing the mount options to fix this problem, you're going to break something else.

Why isn't the trashcan user-neutral or user-specific or whatever works here?

touristguy87 (touristguy87) wrote :

this also is nonsense:

"i suggest using .trash-{user}, and having the contents of that folder appear in the relevant user trash:// folder. if the admin cares about security of files it will be obvious that no files should ever be stored on the ntfs drive (or get rid of the drive), if the admin lets the users store file on this drive, then it is clear that the admin is relying on trust between the users when dealing with files on..."

....don't assume that someone who doesn't know as much as you do agrees with you about what they are doing.
In fact you shouldn't ever assume that another person agrees with you about what they are doing.

In this case the issue is plain and simple. Putting one of my image files in the trash merely by hitting the delete key when I'm looking at the image in the viewer. This has nothing to do with a security issue and no assumptions about security should be made! I just want to delete one of my files on an NTFS partition without having to go into another app to do it, not open that drive up to malicious files.

Forget all this! Just don't even think about this at all. How do I fix this app so that it will move an open image to the trash, if the image is on an NTFS partition which is apparently the problem, assuming one thing: that the image isn't write-protected, that this isn't an issue of file-rights. Period. End of issue.

If it's an issue of file-rights I will be happy to chmod the entire drive.

Thah is not the problem when it tells me that the trash cannot be found.

touristguy87 (touristguy87) wrote :

"That's not the permission of the file you are deleting which matter but the ones from the trash directory. The issue when this directory is not owned by your user is that other users can see things you have deleted which can be a security issue."

Please don't tell me that the people who are responsible for fixing the bugs in Ubuntu are this stupid.

Anything can be a "security issue".

It doesn't matter whether the user "owns" ANY directory on the machine ANYWHERE. The point is that they want to delete a file that they have write access to, and they can't do it. That's it. That's all.

It doesn't matter who owns the file...who owns the directory...who else can see the file, or the directory.

The fact that I'm the only user on a single-user workstation is irrelevant here. Anyone who can open the file and write to the file should be able to delete it, regardless of whatever the partition type is, regardless of whatever app they use to delete it.

Chris Coulson (chrisccoulson) wrote :

touristguy87 - Please don't comment unless you have anything constructive to say that will help fix the bug. Your comments are unhelpful, rude and disrespectful. To maintain a respectful atmosphere, please follow the code of conduct - http://www.ubuntu.com/community/conduct/ . Bug reports are handled by humans, the majority of whom are volunteers, so please bear this in mind.

touristguy87 (touristguy87) wrote :

Your opinion is noted, but as I replied to you by email (and I do believe that this is "helpful" to ask you again here):

What level of respect and politeness should we give to stupidity?

There comes a point where the problem is not that *I* am rude or disrespectful, it is that so many of the people involved with this are just plain stupid. What's your solution?

touristguy87 (touristguy87) wrote :

and beyond that I think that my comment was extremely helpful and it's dismissive of you to say otherwise.

I've been following this bug pretty much forever now, and I have to say I
think touristguy is not being rude or disruptive, but is bang on the mark.
The discussion was wondering off track and needed pulled back to the point.

Talk of admins granting permission to users, choice of file systems etc is
irrelevant. When I (admin and single user on 3 machines) hit the delete key,
I want the file (created, owned and writeable by me) to be sent to the trash
can. I don't care if it's on my external ext3 hard drive, my reiserfs home
partition or my vfat SD-based camera.

The fact that this doesn't happen is a bug. Let's not get bogged down in
silly rants about security, inexperienced users and "other" systems but, as
touristguy said, let's get this silly, long running and extremely irritating
bug fixed.

2009/4/10 touristguy87 <email address hidden>

> and beyond that I think that my comment was extremely helpful and it's
> dismissive of you to say otherwise.
>
> --
> "Cannot move file to trash, do you want to delete immediately?" on NTFS /
> VFAT partitions
> https://bugs.launchpad.net/bugs/192629
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in The "G" Library - GLib: New
> Status in “glib2.0” source package in Ubuntu: Triaged
>
> Bug description:
> Trying to delete files with nautilus from a vfat partition "fails". Well,
> the file can be deleted OK, but it seems gvfs can't send the file to the
> trashcan, so only permanent delete is available. Furthermore, the name of
> the file appears in little boxes, similar to viewing a chinese site using
> Latin-1 encoding (will attach screenshot).
>
> Distro: Hardy up to date (17-february 2008)
>
> Steps to reproduce: Copy a file to an vfat partition. Select it and delete
> using nautilus. A message error will appear:
> "Can't move file to trashcan. Do you want to delete it inmediately?"
> "File <<little-boxes>>cannot be moved to trashcan"
>
> Versions:
> Nautilus 1:2.21.91-0ubuntu2
> gvfs 0.1.7-0ubuntu4
>
> /etc/fstab for the vfat partition:
> UUID=9445-A956 /fat32 vfat defaults,utf8,umask=007,gid=46 0
> 1
>

--
http://www.monthofsaturdays.net

touristguy87 (touristguy87) wrote :

..I also suggest that if a solution runs through creating a personal (and "secure") trashcan for the user who is attempting to delete the file (again assuming that they have the proper properties with respect to the file), then please do that.

If it involves resolving a chmod mismatch then please do that.

But changing the mount-options seems to be a big can of worms, unless...they really need to be changed, not just for this. If *that* is the answer then please do that.

But whatever is done...please, let it be intelligent, well-though-out, and not cause more problems than it solves.

...and timely...

Sebastien Bacher (seb128) wrote :

you should really discuss on the bugzilla bug where people writting the code will read your concerns and not only distributions bug triagers

irishbreakfast (v-spagnolo) wrote :

I just tried changing the mount of the ntfs partition to gid=1000. For me, using 9.04, this did not change the behaviour of trash at all. That is, I can only delete from the ntfs partition.

This behaviour is one of the reasons I don't promote ubuntu to others.

touristguy87 (touristguy87) wrote :

Sebastien, then please include a link to the bugzilla bug in your comment.

That will help people to negotiate the issue in a more productive way.

re:
"Security concerns dont really exist with trash folders on shared drives:
If you delete a file that was public on an ntfs drive, you expect it to go to your trash, and will expect it to still be public, and if you really want to get rid of it you will know you have to empty your trash"

I don't agree with this. As a user I don't want my files becoming public just because I delete them.
Of course that may be what happens (and if so then I should be made aware of this due to the security implications) but still.

I agree that this is not a straightforward problem from a security standpoint. But there is a straightforward *solution* from a security standpoint. Just create a trash folder for each user. To raise the old "how is it done in Windows?" hairshirt, think about that. Just what happens if a person with user priviledges deletes a file? It goes into a *common* trashcan. Does that change the privileges of the file? Probably not. If that's not an issue but the OS crowd doesn't want to follow that model, then just create separate trash cans for each user. Be consistent.

Re: NTFS files becoming 'public' when deleted. The NTFS file system does not recognise the concept of file ownership. So any file, no matter who 'owns' it, can be seen by all users if they know where to look. (I believe some windows versions have file ownership implemented from the operating system level, but this is of course meaningless if you're not running windows when you access the file.)

Ozzyprv (ozzyprv) wrote :

I totally agree with Andrew Simpson (what he wrote on 2009-04-10). It is a bug, no matter how you put it.
Particularly since it was not there before (< 8.04, I think).

If this is not the right place to post this, trying to get it fix (by the kind volunteers), please let me know where should I go.

Thanks.

Sebastien Bacher (seb128) wrote :

the bugzilla URL is in the table at the start of the webpage for this bug

Matt Joiner (anacrolix) wrote :

Adding uid=1000,gid=1000 to the mount options solves this for me (on a single user machine).

UUID=<uuid> /media/data ntfs-3g utf8,umask=007,uid=1000,gid=1000 0 2

"Adding uid=1000,gid=1000 to the mount options solves this for me (on a single user machine)."
Ditto. I have two users on mine, and it works just like I want.

BTW, there was no problem with a vfat flash drive. The only problem was when this drive was a hd partition. I believe that a partition like this should be treated the exact same way that a flashdrive is when inserted. There should be a trash can, so you don't have to risk completely loosing your data b/c you hit the wrong button or your mouse frizzed out for a second.

This would be better than Windoze. Micro$oft has a trash option for fat32 partitions, but not for media such as flash drives.

I have a suggestion that may help. Why not just inform users a little better. The error message could say something like, "...cannot move the file to the trash can for security reasons. Do you want to delete anyway?" (Add the words "for security reasons".)

That would at least give the user an explanation, and a hint that there is a good reason. I think most users would accept it then. The way it looks now, it appears as if something is just broken.

This would be a cheap solution, or partial solution, but it would require another bug report. Would it work? Discussion?

YannUbuntu (yannubuntu) wrote :

I definitely agree, that would be a good improvement.

I wish also a simple way to desactivate this security restriction.

touristguy87 (touristguy87) wrote :

that just papers over the problem with a dirty, stupid piece of paper.

It says, "ok, because of some abstract security concern that say 5,000 people have, who don't at any point in time work on your system, we are consciously not going to allow you to delete these files from this drive at this time".

The core issue here is that the only reason that this is a problem is that the partition format is ntfs vs vfat or whatever. That's all there is to this. The solution is to mount the drive in a way that gives the user access to the drive that is consistent with all other drives. If the only problem is someone's abstract "security concern" realize that their opinion is just as likely to be a PROBLEM as a solution. Just as it is here.

At least, that's the SENSIBLE solution to a bug that should never have been a problem in the first place not to mention a year after I filed a bug report on it. At this point I'm tempted to just delete this entire bug report for the fact that too many people involved in this have their heads 6 feet up their asses! In the list of problems that I can think of with Ubuntu this is a minor issue yet the fact that it has yet to be resolved? I can see why there are such problems in the first place! Your opinion as to whether or not I should be "allowed" to delete a file on my own system is ENTIRELY IRRELEVANT. Unless the user is clearly prohibited from doing so because of the mounting configuration, please get the hell out of the way and go away.

Now the question becomes how exactly do you, as OS programmers, handle mounting various formats, by default, to the Ubuntu desktop, knowing that, by default, out of legitimate security concerns, the user is likely not logging in as root but still very likely actually owns all the media associated with the system not to mention the files on said media?

That is the SOLE question here that is of any merit.

And the sheer fact is that if I'm sitting here on my Ubuntu laptop and I have an external drive formatted in NTFS that I formatted on another system and I have files on it that I created and put on that media that I want to delete? I want to delete them. Now. Period.

How you get from point A to point B is not my concern as long as you get from point A to point B, not take a huge long detail to point C which is where your head is somewhere deep in the recesses of your colon, and then never actually bother to get to point B because you feel that it isn't what's really important. What's really important to you is having your head lodged near point C in a warm and comfortable manner.

Is that clear?

Jesus Christ!!!

It's like you guys are doing everything that you can do to make it clear that if you really want to use a user-friendly yet competent PC OS, Ubuntu is not the way to go. If for no other reason than it is a window into the colons of the creators.

touristguy87 (touristguy87) wrote :

In other words stop putting your security concerns above the issue and solve it!

If you want to keep your smelly security concerns next to your heart, FINE but SOLVE THE PROBLEM.

Otherwise the user has one more good reason to just rip the OS off and revert to Windows. What about your security concerns then? Keep this up and you will have the most secure OS that no one uses.

A frigging YEAR now, at least, I posted this bug. Still an issue! Good Grief!

Let me think. Ok I have a hard drive attached to my PC. I'm running Ubuntu. Ubuntu says that because it would be insecure to allow this, we can't just allow normal users to delete files from an NTFS partition by default. Hm, so if I'm a dastardly user with criminal intent how do I get around this, hm. Gee, those default-configuration security restrictions are so effective at stopping me from accessing and even deleting those files. Whoops, I can access them just fine. I just can't DELETE them.

You pinheads are arguing about whether the barn door should be allowed to be closed by a generic farmhand by default long after the horses have left the barn, or whether the farmhand should have to go and fetch the owner just to get the door closed, on the sheer basis that maybe just fing maybe the owner wouldn't want the farmhands to be able to close the barn door after the horses have been let loose, but *would* want them to be free to open the door and let the horses out in the first place. How freaking stupid can you get.

Miguel Martinez (el-quark) wrote :

touristguy,

If you read your own bug report, you will see that you can actually delete files from an NTFS or VFAT partition without issues.

YannUbuntu (yannubuntu) wrote :

Wow, it looks that this bug is solved ?
I just tried the following on Ubuntu 9.10:
- mount my NTFS partition
- put 1 image file and one music file in my NTFS partition
- open them with Rhythmbox and Evince
- put them in the trash via these applications.
It works !
(maybe because the partition is not automatically mounted ?)

Everybody confirms it is solved ?

I'm not sure I have the exact same bug, but better post here before starting a new one I guess.

- I also have the "can't access trash" problem when trying to delete an image from eog from an NTFS drive (where I have write permission everywhere).
- Nautilus is however able to delete the exact same file, from the exact same place (i.e. the NTFS mounted drive). I don't know what Nautilus does with the file however. AFAI can see, the file is simply "deleted", because I can't find it in my usual trash nor in the RECYCLER dir in the NTFS drive, and don't see any folder which would have been possibly created by nautilus on the root path of the NTFS drive for that purpose (as it does on my USB keys).

It would seem appropriate, IMHO, that eog does the same thing when I ask it to delete a file than Nautilus does. I am not sure that Nautilus' apparent choice of permanently deleting the file without asking is the best choice, but that seems to be a difficult discussion I don't want to enter into... And if the Nautilus choice is well thought, every gnome application should have the same behavior I guess... And, finally, anything would probably be better than the current situation ("can't delete").

I am running Ubuntu 9.04 up to date. (FYI, my problem seems to be exactly like https://bugs.launchpad.net/ubuntu/+source/eog/+bug/42571, at least from a user point of view.)

Since this "bug" is long since triaged, another bit of bug spam probably won't hurt. This bug report is a mess.

I notice that the original report is about vfat. I missed that the first time, since many of the comments are about ntfs. Not the same animal. Ntfs has a recycle bin for each user in the Windows file system. Since Linux has no access to the Windows file system, I don't see how it could know which Windows recycle bin to use. That's probably not a bug.

Vfat is an altogether different matter, since it has no user access restrictions. I don't know if there's a bug here somewhere, but I'm not going to try to find out. I'm pretty sure there are some user support issues here with mount and fstab, which are both rather complicated.

There's also a matter of etiquette. Just because you think there's a bug doesn't mean that someone is obligated to make your computer work for you the way you think it should. If anyone still has questions about this, you'll probably do better to discuss it in the forums.

touristguy87 (touristguy87) wrote :

...comments like this from developers are why Linux will never be taken seriously as a business OS.

Comments like this from users are why IT professionals will never take users seriously.

Hi, touristguy87, not sure what you mean by "this"....

But I just checked, using Ubuntu for a proper view of the files. The Windows XP Recycler folder does indeed use different subdirectories for different logon users. So if I'm not mistaken, there appears to be a LOGICAL reason, and not just a security reason, why Linux has difficulty supporting the Windows Recycle bin (since no Windows logon user is defined).

Regardless of what this bug is about, VFAT would appear to be a different problem than NTFS, since VFAT does not distinguish between users.

Changed in glib:
importance: Unknown → Medium
ha el rai (haelrai) wrote :

You must add uid=1000 and gid=1000 to resolve this problem.

Change the FSTAB file like shown below.

/dev/sdb1 /media/SONGS vfat defaults,users,umask=000,uid=1000,gid=1000 0 1
/dev/sdb5 /media/BACKUP vfat defaults,users,umask=000,uid=1000,gid=1000 0 1
/dev/sdb3 /media/FILES40NEW vfat defaults,users,umask=000,uid=1000,gid=1000 0 1

Save the file and restart the computer. Create a folder called .Trash-1000 in the root of these partitions. Now, when you delete a file from these VFAT partitions, the files will move to Trash directly.

reference
http://ubuntuissues.wordpress.com/2008/06/19/cannot-move-files-to-trash/

David Pérez (sanete) wrote :

The solution proposed in #8 works ok for me. Thanks a lot.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.