Bob, thanks for your very informed response, from which I'm learning
a lot. On 06/17/2015 12:10 AM, Bob Proulx
wrote:
Here's a copy from the initial post that says what I'm trying to do. And to be more specific: on the disk is just data. It's not the root of an OS. Now the original post:You haven't really included enough information in the thread yet. You are mounting an ext4 file system over a USB disk. What, in general, is on the disk? Is only your own data? Is it the root of an operating system? This is rather important. If I suggest a recursive chmod it will destroy an operating system. But if it is only your own data files, an external $HOME backup for example, then that is fine. Here's what my fstab says: / was on /dev/sda1 during installation UUID=c90b11e8-7021-4a16-a692-8ffa91781753 / ext4 errors=remount-ro 0 1 # swap was on /dev/sda5 during installation UUID=d4bfa613-8518-4338-b33c-d08663f5b2f9 none swap sw 0 0 /dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0 Is this correct? I found it as I'm having trouble mounting an external usb hard drive now. And that the USB hard drive is not in the fstab, though "mount" produces, which is the drive: /dev/sdb2: LABEL="300gb" UUID="02db0acc-97b3-40b8-b9a1-f6d5fee78e1f" TYPE="ext4" And I went to go add that to my fstab, so perhaps the "permission denied" notice I get when I try to use Thunar to mount it would go away. And after putting this line in fstab, it still won't work: /dev/sdb2: LABEL="300gb" UUID="02db0acc-97b3-40b8-b9a1-f6d5fee78e1f" ext4 -o uid=1000,gid=1000,utf8$ My current fstab concerning the line: /dev/sdb2 /media/a3a3/300gb ext4 rw,user,noauto 0 0 I have tried these and have learned from them. Thanks.Since ext4 is a full Unix-like file system all files are owned by users and groups. The file system never stores names. Everything is stored by number. The first user on a Debian system is usually 1000 by number. You can tell this by looking at the output of the 'id' command and by listing files in your home with 'ls -l -n'. Thanks for your input. I was about to try this last chown command but thought I'd wait and see if I'm on the right track on that.If you are the second user then your uid is usually 1001 and the next 1002 and so forth. Transporting files on the file system drive from one system to another the other system might have different uid numbers. Let's say you were 1001 on one system but 1000 on a different system. The numbers would not match. You as uid=1000 would not have permission to modify uid=1001 files. Of course root on the system mounting that disk would have permissions. I tend to never modify backup files. I tend to always mount backup copies read-only to prevent accidents to the backup. If the backups had uid=1002 and I needed to recover them to 1001 then I would copy the files off backup without modifying them. Then in the recovery area I would modify the new copies to be the right user. Tools such as cp simply copy files and permissions from the source to the destination. Tools such as rsync are fancy and try to map uids. Both tools have options to control this behavior. $ cp --help | less --preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,time- stamps), if possible additional attributes: context, links, xattr, all --no-preserve=ATTR_LIST don't preserve the specified attributes $ man rsync --numeric-ids don't map uid/gid values by user/group name Additionally rsync has many options for controlling this and various behavior. See --usermap=STRING, --groupmap=STRING for example. Let's say I ignore those options for the moment. Let's say I copy those files from backup to recover them. # rsync -av /mnt/path/to/backup /home/foo/restore/ That will probably leave the uids:gids owning the files incorrect. They will be as on the source mapped through the local /etc/passwd file mapping. After restoring them they will need to be corrected. # chown -R user1:user1 /home/foo/restore That will recurse (-R) down the /home/foo/restore directory tree and change the ownership and group of everything to user1:user1. Since I don't know what is on your usb disk it is hard to give specific advice. I can only say the above in general terms. Modify as needed for your situation. Currently this command "rsync -av /mnt/media/a3a3/300gb/ /media/a3a3/duopro/New/" Gives this: "sent 20 bytes received 12 bytes 64.00 bytes/sec total size is 0 speedup is 0.00 rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.1]" None of the "fixes" online have solved the "code 23" error. Thanks! |