[Bug 192629] Re: Cannot send files to trashcan from an ntfs partition
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. -- Cannot send files to trashcan from an ntfs partition https://bugs.launchpad.net/bugs/192629 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 192629] Re: Cannot send files to trashcan from an ntfs partition
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 4883840017 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 -- Cannot send files to trashcan from an ntfs partition https://bugs.launchpad.net/bugs/192629 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 192629] Re: Cannot send files to trashcan from an ntfs partition
I have a similar problem (Bug #230105, sorry for the duplicate) Now my etc/fstab contains as follows: /dev/sda4 /data vfatdefaults,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? -- Cannot send files to trashcan from an ntfs partition https://bugs.launchpad.net/bugs/192629 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 192629] Re: Cannot send files to trashcan from an ntfs partition
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 this drive, so the
trash system i just described is appropriate, and isnt any more
vulnerable to attack or security comprimise.
--
Cannot send files to trashcan from an ntfs partition
https://bugs.launchpad.net/bugs/192629
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
