Version: 1.4 (using 4.4.2 (KDE 4.4.2), Kubuntu packages) Compiler: cc OS: Linux (i686) release 2.6.31-21-generic Not really sure if this is a KDE issue or an OS issue, or a .... Background: Kernel: 2.6.31-21-generic i686 (32 bit) Distro: Kubuntu 9.10 karmic KDE: 4.4.2 External HDs: USB 60GB and USB 30GB The 60GB drive has a single primary partition formatted as ext3. The 30GB drive has a primary partition formatted as fat32, an extended partition with two logical partitions formatted as ext3. The 60GB drive had nothing on it. The 30GB drives two ext3 partitions had nothing on them. The issue / quirk When accessing the 30GB ext3 partitions via Dolphin, I, as the user, had no write permissions to the partitions. The same was true of the 60GB single ext3 partition. With them mounted (having been accessed by Dolphin), I checked the Permissions > Ownership (User:Group) of the mount points in /media for each of them. All three were root:root. That isn't right. These USB HDs are not identified in my fstab file by choice - my PC is a laptop, and I sometimes travel with it and don't take the external USB HDs with me when I do. Mounting of these two HDs is to be done 'on demand' when I have them connected. The fix I fixed this issue as follows: With all three partitions mounted (by Dolphin), I navigated to /media and right-clicked on each of the mount point folders, selected Root Actions > Ownership to... and clicked No, then typed paul:root and clicked OK. As the user, I now have write access to the ext3 partitions on both USB HDs. This remains true even after a shutdown and system reboot. It appears that if one sets up an external USB HD formatted as ext3 (and maybe other Linux FS types) and has nothing on it, and doesn't identify it for user access in /etc/fstab, that the user wont have access to it when it is accessed (mounted) 'on demand'. I don't believe that this is/was the intended behavior.
> dir /media/disk/backup4 -d drwxr-xr-x 11 user users 4096 9. Apr 11:40 /media/disk/backup4 The owner of backup4 is "user" NOT "root". Example: > cd; cd .kde4/share/apps/kmail/mail/; rsync -av --delete . /media/disk/backup4/mail/ ; cd
I've observed that USB memory sticks are treated properly. USB Hard Disks, like "My Passport", are not. When I copy directories or files to my USB Hard Disk my ownerships are changed from "jerry:jerry" to "root:root", AND, my permissions are changed to rwxrwxrwx, making the files accessible to the WORLD! When I copy them back to my home account (or any other user's files) the ownership is changed from "root:root" to "jerry:jerry" but the permissions remain as rwxrwxrwx
> dir /media/disk/ -d drwxr-xr-x 9 root root 4096 23. Aug 2009 /media/disk/ (ext2) > dir /media/disk/backup4/ -d drwxr-xr-x 11 user users 4096 9. Apr 11:40 /media/disk/backup4/ (ext2) > dir /home/user/ -d drwxr-xr-x 46 user users 4096 15. Apr 11:16 /home/user/ (ext4) I as "root" created "backup4/" and then changed ownership and group so that they are same as in "user/" (commands: chown, chgrp, [chmod]). Now owner "user" can copy files from folder user/ to backup4/ in Linux file systems.
(In reply to comment #2) Please disregard my comment. I thought I had formatted "My Passport" to EXT4, but I had not. It was still formatted NTFS, and thus the ownership and permissions were defaulted to and unchangeable from root:root rwxrwxrwx. :( As an EXT4 USB HD it is behaving as I would have expected.
The automount feature of a external HDD is managed by HAL (at OS level) and/or Solid (at KDE level). There is a simple solution for it (I use it in my external drivers). Create your contents inside a folder (created by root and changed owner to your user) of the external HDD file system. This simple solution keeps the unix multi-user rights working even if the external HDD is plugged by other user.
I'm not sure, but shouldn't the permission settings be hal dependant? Anyway the behaviour described by the reporter is exactly what I expect on a *nix system. I would consider this bug as invalid.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!