how restore default permissions root folder after copy OS to SSD?

deepforest · 2024-08-16 01:42:00

i am copy OS disk partition(all dirs\files) to SDD with sudo permissions,
cloned OS working, but Thunar now show content of mounted drives it say "permission deny",
how restore permissions at new cloned OS at SSD?

UPD
i am use this instruction for clone os to another drive
https://askubuntu.com/a/741727

Last edited by deepforest (2024-08-20 02:08:03)

steve_v · 2024-08-16 10:39:41

You didn't mention how you copied the system. Did you preserve extended attributes (and in particular, POSIX capabilities)?
I have no idea how thunar handles user mounts these days (still GVFS?), but I wouldn't be at all surprised if there's a binary with CAP_SYS_ADMIN set to allow (un)mounting filesystems involved.

deepforest · 2024-08-20 01:51:26

thanks for reply,
i am copy os use midnight commander,
at first i try copy as non sudo user but mc say that needed sudo permissions for copy os to another drive,
copy Devuah i did under Artix linux that installed in dual boot at another partition

how thunar handles user mounts these days (still GVFS?

maybe so

ps
i do not know is it right way but me help
chmod -R 775 *

Last edited by deepforest (2024-08-20 01:54:31)

stargate-sg1-cheyenne-mtn · 2024-08-20 11:09:47

copying _anything_ in an incorrect way has the potential to alter ownerships and/or permissions
(hard to check 1000's of files/folders for complete correctness)

hopefully your original is _still_ intact and completely correct

unless you can verify the complete correctness of any/all copies you should consider them _not_authentic_duplicates_
(especially and specifically with respect to ownerships and permissions)

also, just to clarify, a backup isn't a backup if it is just on a different partition of the same physical device

operations on the underlying formating/partitioning of any/all storage devices should be considered totally destructive of _all_data_ on that device

keep us posted on your progress!

steve_v · 2024-08-20 11:20:09

copy os use midnight commander

A thouroghly terrrible idea, as is using any other TUI or GUI file manager for this. Use rsync or plain cp, in archive mode or with explicit --preserve= parameters.

needed sudo permissions for copy os

No kidding. Of course you need root.

chmod -R 775 *

Yeah, don't do that either, unless you want to completely bork permissions.

UPD
i am use this instruction for clone os to another drive
https://askubuntu.com/a/741727

That post details using 'cp -a' to copy files, not mc.

The easiest way to fix this is almost certainly just copying the system again, this time with the right tools and options. You did make and test a backup before starting, right?
Personally I suggest using rsync from a liveCD/USB, or at least single-user mode so there aren't too many open files. Then run it again so it can verify the copy is correct.

Last edited by steve_v (2024-08-20 11:24:08)

alexkemp · 2024-08-20 11:23:42

Simple answer:
Use rsync -aH to copy files across.

That can be done as many times as required. It is also intelligent enough to only update metadata & not try to do an unnecessary 2nd copy of data if permissions are the only change.

User479 · 2024-08-21 02:55:56

Even better: rsync -aHX

The "X" will preserve extended attributes and capabilities - kinda important for OS files.

stargate-sg1-cheyenne-mtn · 2024-08-21 08:43:02

have used clonezilla and partedmagic for many years with much success

clonezilla is free
https://en.wikipedia.org/wiki/Clonezilla

partedmagic is more "full-service" and well-worth their minimal charge(imho)
https://en.wikipedia.org/wiki/PartedMagic

deepforest · 2024-08-22 00:52:07

@all thanks for explanation and good advices
yes, original Devuan 5 at hdd still alive,
so, how better remake clone to ssd?:
1. cp --archive/--preserve=all/--preserve=xattr
2. rsync -aHX
3. clonezilla

ps and if clone will succesed how install grub to ssd?

Last edited by deepforest (2024-08-22 00:52:58)

deepforest · 2024-08-22 13:39:59

i did

home:[freeartist-artix]:~$ sudo rsync -aXHx --info=progress2 /mnt/Dev1/ /mnt/Dev2/
 18,553,600,204  74%    9.40MB/s    0:31:21 (xfr#423384, to-chk=0/585833)
home:[freeartist-artix]:~$

update grub, cloned ssd os booted ok, but still have permissions problem

root@home:~# sudo mount /dev/sdc1 /mnt/
[  262.998370] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Quota
mode: none.
root@home:~#

freeartist-devuan@home:~$ sudo su
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
freeartist-devuan@home:~$

freeartist-devuan@home:~$ sudo su
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[sudo] password for freeartist-devuan:

some help this

sudo chmod a+w /tmp
chown root:root /usr/bin/sudo && chmod 7455 /usr/bin/sudo

now desktop, xorg, slim worked, but at thunar i cant see any storage devices
where is issue again?
what i am did wrong?

Last edited by deepforest (2024-08-22 13:40:29)

alexkemp · 2024-08-22 18:59:48

use su - ("switch user to root") not sudo su. sudo by itself is "switch user to root one-time only".

This is the content of /etc/sudoers.d/README:

#
# The default /etc/sudoers file created on installation of the
# sudo  package now includes the directive:
# 
#       @includedir /etc/sudoers.d
# 
# This will cause sudo to read and parse any files in the /etc/sudoers.d 
# directory that do not end in '~' or contain a '.' character.
# 
# Note that there must be at least one file in the sudoers.d directory (this
# one will do).
# 
# Note also, that because sudoers contents can vary widely, no attempt is 
# made to add this directive to existing sudoers files on upgrade.  Feel free
# to add the above directive to the end of your /etc/sudoers file to enable 
# this functionality for existing installations if you wish! Sudo
# versions older than the one in Debian 11 (bullseye) require the
# directive will only support the old syntax #includedir, and the current
# sudo will happily accept both @includedir and #includedir
#
# Finally, please note that using the visudo command is the recommended way
# to update sudoers content, since it protects against many failure modes.
# See the man page for visudo and sudoers for more information.
#

For the record:

$ la /usr/bin/sudo
-rwsr-xr-x 1 root root 281624 Jun 27  2023 /usr/bin/sudo

deepforest · 2024-08-23 11:35:38

ok, but why after using rsync, permissions is broken again!?

Last edited by deepforest (2024-08-23 11:36:10)

deepforest · 2024-08-25 04:05:07

use su - ("switch user to root") not sudo su. sudo by itself is "switch user to root one-time only".

but why sudo worked at sourcre old hdd Devuan, and after rsync -aXHx at ssd not?

alexkemp · 2024-08-25 12:53:55

Did you use either su - or sudo (latter all by itself rather than 'sudo su')? If so, what were the error messages?

nixer · 2024-08-25 14:33:35

i did
home:[freeartist-artix]:~$ sudo rsync -aXHx --info=progress2 /mnt/Dev1/ /mnt/Dev2/

Allow me to ask, what operating system did you use to copy the source partition to the destination partition? Devuan or another?

I do rsync copying pretty often and I recently had a situation where I had to add "--numeric-ids" to the rsync command. This was because there was a different operating system involved in the mix, not just devuan. In this instance I used devuan to host a Void virtual machine and I copied the virtual machine onto a locally mounted partition. Essentially, I moved a VM onto a physical partition. It worked fine after the fstab file was altered with the new UUID's, grub reinstalled, and the initramfs was rebuilt.

The actual command used that worked for me, from a VM to a locally mounted partition:

rsync -aHAXv --numeric-ids --exclude={"/dev/*","/proc/*","/sys/*","/run/*","/media/*","/mnt/*","/lost+found"} /* root@10.0.0.1:/media/User/Void/ --delete

Hope this helps.

Last edited by nixer (2024-08-25 14:42:11)

deepforest · 2024-08-25 18:37:48

@nixer Thanks for reply.
Yes i use Artix for copy Devuan. But where is mistake? Why i cant use another linux os here? Please explain. At many instuctions that i read i am not seen any warnings about type os for copy another os, just it all say "use live os"

deepforest · 2024-08-25 18:39:49

@alexkemp

If so, what were the error messages?
freeartist-devuan@home:~$ sudo su
sudo: /usr/bin/sudo must be owned by uid 0 and have the setuid bit set
freeartist-devuan@home:~$
freeartist-devuan@home:~$ sudo su
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[sudo] password for freeartist-devuan:

delgado · 2024-08-25 18:56:27

Interesting command lines for rsync, indeed.
I'll stick to cat (or dd) a partition and resize2fs the file system to the target partition's size.

nixer · 2024-08-25 19:31:45

As a suggestion, I mentioned adding the "--numeric-ids" option. It seems that by default rsync will sync user information as user:group and not UID:GID, which can cause some permissions issues. The "--numeric-ids" will change this behavior. The user and group name will still copy over but this seems to fix any issued caused by a different operating system handling the rsync data. Sorry for not being too technical but a search request reveals this:

--numeric-ids With this option rsync will transfer numeric group and user IDs rather than using user and group names and mapping them at both ends. By default rsync will use the username and groupname to determine what ownership to give files.

Hey, I tried it and it worked. So, I thought I would mention it as it sounds like you are having similar issues.

alexkemp · 2024-08-25 19:58:44

deepforest wrote:

@alexkemp

If so, what were the error messages?

freeartist-devuan@home:~$ sudo su
ERROR: ld.so: object 'libgtk3-nocsd.so.0' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
[sudo] password for freeartist-devuan:

Since you are someone that ignores the advice that you are given, and yet expects others to keep giving help regardless, I'm backing out of this thread at this point.

deepforest · 2024-08-26 12:36:10

@alexkemp
ok, but where is help? i am always use sudo su, and is my habit, and it always worked for me, but after rsync not.
I just want to show that Linux is still an wonky and shaky system.

deepforest · 2024-08-26 12:40:16

@nixer

user:group and not UID:GID, which can cause some permissions issues

if it so, why this important thing not mentioned in the rsync manual at first place?

nahkhiirmees · 2024-08-27 17:36:07

After reading first few messages of this topic, i was going to suggest "tar -cp" and "tar -xp".
But maybe unmounting and dd'ing the underlying partition from source to destination would be better.
Although those commands are dangerous with wrong parameters, especially when ran as root. But same can be said about cp and rsync also.

E.
'
https://linux.die.net/man/1/tar
https://linux.die.net/man/1/dd

Not 100% sure about those acl's, attributes or capabilities while using tar's "-p" - option. But owners and access rights should go into archive and out of it.
(Once or tiwce managed to screw up my OS with those options.)

And then there are some fs-specific things with dd. Ext-family of filesystems better be unmounted while doing dd.
And with xfs there may be some problems when there are 2 filesystems with exactly same identifiers.
Other than that, i like to think that dd should be thorough enough even if tar's -p isn't.

For beginners, maybe Clonezilla would be a good idea. Haven't tried it myself though.

Last edited by nahkhiirmees (2024-08-27 17:50:16)

nahkhiirmees · 2024-08-27 18:05:42

... and if going the "dd-route" , one should make the destination partition first, for example with fdisk(https://linux.die.net/HOWTO/Partition/f … oning.html) (or lvcreate(https://linux.die.net/man/8/lvcreate) if using lvm).

Destination_partition cannot be smaller than source_partition or data loss will occur.

... and if the destination_pari is bigger than source, resizefs https://linux.die.net/man/8/resize2fs could be a good idea afterwards. Assuming the fs is ext_something_fs. With other filesystems there are other commands for resiuzing, maybe.

And rezize2fs will propably require to run e2fsck before the actual resizing.

Last edited by nahkhiirmees (2024-08-27 18:14:42)

deepforest · 2024-08-27 20:34:08

if i use dd it copy not files but sectors,
how use dd if destination bigger/smaller then source partition?

The officially official Devuan Forum!

#1 2024-08-16 01:42:00

how restore default permissions root folder after copy OS to SSD?

#2 2024-08-16 10:39:41

Re: how restore default permissions root folder after copy OS to SSD?

#3 2024-08-20 01:51:26

Re: how restore default permissions root folder after copy OS to SSD?

#4 2024-08-20 11:09:47

Re: how restore default permissions root folder after copy OS to SSD?

#5 2024-08-20 11:20:09

Re: how restore default permissions root folder after copy OS to SSD?

#6 2024-08-20 11:23:42

Re: how restore default permissions root folder after copy OS to SSD?

#7 2024-08-21 02:55:56

Re: how restore default permissions root folder after copy OS to SSD?

#8 2024-08-21 08:43:02

Re: how restore default permissions root folder after copy OS to SSD?

#9 2024-08-22 00:52:07

Re: how restore default permissions root folder after copy OS to SSD?

#10 2024-08-22 13:39:59

Re: how restore default permissions root folder after copy OS to SSD?

#11 2024-08-22 18:59:48

Re: how restore default permissions root folder after copy OS to SSD?

#12 2024-08-23 11:35:38

Re: how restore default permissions root folder after copy OS to SSD?

#13 2024-08-25 04:05:07

Re: how restore default permissions root folder after copy OS to SSD?

#14 2024-08-25 12:53:55

Re: how restore default permissions root folder after copy OS to SSD?

#15 2024-08-25 14:33:35

Re: how restore default permissions root folder after copy OS to SSD?

#16 2024-08-25 18:37:48

Re: how restore default permissions root folder after copy OS to SSD?

#17 2024-08-25 18:39:49

Re: how restore default permissions root folder after copy OS to SSD?

#18 2024-08-25 18:56:27

Re: how restore default permissions root folder after copy OS to SSD?

#19 2024-08-25 19:31:45

Re: how restore default permissions root folder after copy OS to SSD?

#20 2024-08-25 19:58:44

Re: how restore default permissions root folder after copy OS to SSD?

#21 2024-08-26 12:36:10

Re: how restore default permissions root folder after copy OS to SSD?

#22 2024-08-26 12:40:16

Re: how restore default permissions root folder after copy OS to SSD?

#23 2024-08-27 17:36:07

Re: how restore default permissions root folder after copy OS to SSD?

#24 2024-08-27 18:05:42

Re: how restore default permissions root folder after copy OS to SSD?

#25 2024-08-27 20:34:08

Re: how restore default permissions root folder after copy OS to SSD?

Board footer