[Resolved] ntfs backup restore, incorrect permissions

babel_f1sh · 2024-04-05 21:18:04

I am having a very similar issue after migrating my installation to a new ssd. Details here (#6). The autologin method didn't work and my ssh fails to start at boot. I have reset the password to a simple one and created a new user with no password. No account (including root) allows me to login.

Last edited by babel_f1sh (2024-04-06 12:40:19)

seth · 2024-04-05 21:21:42

I am unable to login.

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
What is the exact error you get?
Chances are you might have shredded /etc/shells in the transfer?
Can you boot the rescue.target? (2nd link below, that should get you a root shell)

babel_f1sh · 2024-04-05 21:35:58

seth wrote:

Please don't paraphrase, https://bbs.archlinux.org/viewtopic.php?id=57855
What is the exact error you get?
Chances are you might have shredded /etc/shells in the transfer?
Can you boot the rescue.target? (2nd link below, that should get you a root shell)

I am also getting the "Login incorrect" error. All my installed shells (bash, rbash, fish, sh, git-shell) are present in /etc/shells. I am able to boot the rescue.target, are there any commands I should run from here? Also, when exiting out of the live environment, it hangs right before it reboots or shuts down. I have been holding down the power button to force it to power off. Is this a factor? It also outputs

Failed unmounting /run/archiso/copytoram

babel_f1sh · 2024-04-05 21:44:09

babel_f1sh wrote:

I am able to boot the rescue.target, are there any commands I should run from here?

I do see three outputs that may be of interest when running "journalctl -b -1"

agetty[487]: failed to open credentials directory

login[487]: pam_shells(login:auth): /etc/shells is either world writable or not a normal file

login[487]: FAILED LOGIN 1 FROM tty1 FOR babelfish, Authentication failure

babelfish is the user account I attempted to login as

seth · 2024-04-05 21:44:57

1. "systemctl start multi-user.target"
2. journalctl -b -1 # to see the journal ofthe previous boot w/ a failed login - we need to know *what* fails.
3. crashing the install iso should™ not affect the installed system provided that the drives of the installed system have not been mounted or have been unmounted before the shoutdown

Edit:

/etc/shells is either world writable or not a normal file

This is critical.

stat /etc/shells

It's supposed to be root:root/644

For a list of deviant files:

sudo LC_ALL=C pacman -Qkk | grep -v ', 0 altered files'

Last edited by seth (2024-04-05 21:46:16)

babel_f1sh · 2024-04-05 21:56:45

seth wrote:

stat /etc/shells
It's supposed to be root:root/644

That command outputs

File: /etc/shells
Size: 178        Blocks: 8        IO Block: 4096    regular file
Device: 259,3    Inode: 212730902    Links: 1
Access: (0777/-rwxrwxrwx)    Uid: (    0/    root)    Gid: (    0/    root)
Access: 2024-04-05 12:16:45.584295828 -0700
Modify: 2023-10-30 18:54:40.182061900 -0700
Change: 2024-04-05 02:49:13.740060654 -0700
Birth: 2024-04-05 02:49:13.740060654 -0700

For a list of deviant files:
sudo LC_ALL=C pacman -Qkk | grep -v ', 0 altered files'

This command outputs

sudo: /etc/sudo.conf is world writable
sudo: /etc/sudo.conf is world writable
sudo: /etc/sudoers is world writable
sudo: error initializing audit plugin sudoers_audit

When running the same command without sudo at the beginning, it outputs a long list of programs that all say (Permissions mismatch) at the end. I think rsync may have messed with the file permissions while transferring.

seth · 2024-04-05 22:34:41

I think rsync may have messed with the file permissions while transferring.

Less rsync, more your invocation of it
This is either because you didn't preserve attributes or used a non-POSIX filesystem (FAT32)

https://bbs.archlinux.org/viewtopic.php?id=257561
There's been some upstream development on https://aur.archlinux.org/packages/pacm … ermissions

babel_f1sh · 2024-04-05 22:41:09

seth wrote:

I think rsync may have messed with the file permissions while transferring.
Less rsync, more your invocation of it
This is either because you didn't preserve attributes or used a non-POSIX filesystem (FAT32)
https://bbs.archlinux.org/viewtopic.php?id=257561
There's been some upstream development on https://aur.archlinux.org/packages/pacm … ermissions

Potentially my invocation, though I backed up my system and restored it using the process here. Should I restore my system in a different manner? Maybe use this command instead? My filesystem for the main directory is ext4. Should I install that AUR package and run it from rescue.target?

Last edited by babel_f1sh (2024-04-05 22:41:25)

seth · 2024-04-05 22:54:05

"-aAX" will not have left you with bogus permissions, do the files on the backup still have the proper permissions?

babel_f1sh · 2024-04-05 22:55:06

seth wrote:

"-aAX" will not have left you with bogus permissions, do the files on the backup still have the proper permissions?

How can I check?

seth · 2024-04-05 22:56:36

You eg. stat /etc/shells in your backup?

babel_f1sh · 2024-04-05 23:01:23

seth wrote:

You eg. stat /etc/shells in your backup?

Access output is

Access: (0755/-rwxr-xr-x)    Uid: (  1000/babelfish)    Gid: (  1000/babelfish)

babel_f1sh · 2024-04-05 23:15:17

babel_f1sh wrote:

seth wrote:
You eg. stat /etc/shells in your backup?
Access output is
Access: (0755/-rwxr-xr-x)    Uid: (  1000/babelfish)    Gid: (  1000/babelfish)

This is the output I got when viewing the backup file from my old ssd. Running the same command in the live environment, I got

Access: (0777/-rwxrwxrwx)   Uid: (    0/    root) Gid: (    0/     root)

When checking what the original /etc/shells outputs on my old ssd in the live environment it shows

Access: (0644/-rw-r--r--)   Uid: (    0/    root)    Gid: (    0/    root)

So if I'm understanding correctly, the original backup changed the file permissions?

babel_f1sh · 2024-04-06 01:13:00

I found the root of my issue. I was able to login by changing /etc/shells to having root permissions only. The permissions all throughout my backup had this issue though. Apparently, ntfs drives do not respect file permissions, even with rsync. I will have to make an ext4 partition of my external drive now and backup to that. Hopefully that works. Thanks for pointing me in the right direction seth!

seth · 2024-04-06 06:11:40

I found the root of my issue.

Where, here?

Apparently, ntfs drives do not respect file permissions

This is either because you didn't preserve attributes or used a non-POSIX filesystem (FAT32)

ntfs isn't a posix FS either…

babel_f1sh · 2024-04-06 06:32:31

ntfs isn't a posix FS either…

Yeahhh I had misunderstood what you meant. I thought you were referring to the new root partition. That partition is ext4, but the external drive holding the backup is ntfs. I'm going to reformat that drive once I can transfer the data off of it.

I found the root of my issue.
Where, here?

The /etc/shells file needed to have its permissions set to root only, yes. That allowed me to log in. All of the files in /etc and /usr have incorrect permissions though. I think I just need to make a new backup on an ext4 drive. For those struggling with the "Login Incorrect" error though, what worked for me was running (in the live environment or rescue.target)

chmod 644 /etc/shells

WorMzy · 2024-04-06 11:30:12

Mod note: splitting from https://bbs.archlinux.org/viewtopic.php?id=294580

Arch Linux

#1 2024-04-05 21:18:04

[Resolved] ntfs backup restore, incorrect permissions

#2 2024-04-05 21:21:42

Re: [Resolved] ntfs backup restore, incorrect permissions

#3 2024-04-05 21:35:58

Re: [Resolved] ntfs backup restore, incorrect permissions

#4 2024-04-05 21:44:09

Re: [Resolved] ntfs backup restore, incorrect permissions

#5 2024-04-05 21:44:57

Re: [Resolved] ntfs backup restore, incorrect permissions

#6 2024-04-05 21:56:45

Re: [Resolved] ntfs backup restore, incorrect permissions

#7 2024-04-05 22:34:41

Re: [Resolved] ntfs backup restore, incorrect permissions

#8 2024-04-05 22:41:09

Re: [Resolved] ntfs backup restore, incorrect permissions

#9 2024-04-05 22:54:05

Re: [Resolved] ntfs backup restore, incorrect permissions

#10 2024-04-05 22:55:06

Re: [Resolved] ntfs backup restore, incorrect permissions

#11 2024-04-05 22:56:36

Re: [Resolved] ntfs backup restore, incorrect permissions

#12 2024-04-05 23:01:23

Re: [Resolved] ntfs backup restore, incorrect permissions

#13 2024-04-05 23:15:17

Re: [Resolved] ntfs backup restore, incorrect permissions

#14 2024-04-06 01:13:00

Re: [Resolved] ntfs backup restore, incorrect permissions

#15 2024-04-06 06:11:40

Re: [Resolved] ntfs backup restore, incorrect permissions

#16 2024-04-06 06:32:31

Re: [Resolved] ntfs backup restore, incorrect permissions

#17 2024-04-06 11:30:12

Re: [Resolved] ntfs backup restore, incorrect permissions

Board footer