My backups go to an nfs mounted ext4 partition. So all files are owned by uid 0 or 1000. I don’t have access to my backups atm so can’t check the setuids.
great! sudo is working now and i also can update from the console with keyboard attached to the vero.
ssh still not working. i reinstalled and it appears as running in osmc menu inside kodi but i am not able to connect.
Connection reset by 192.168.x.x port 22
already deleted the entry from the Known_hosts file on my ssh clients system. still not working.
any idea?
What’s sudo systemctl status ssh show?
hmm i guess i can delete the etc/ssh-folder and then reinstall ssh-app from scratch and this will be solved … but: since we had already two permission issues - are you sure restoring a system from backup will result in a reliable performance?
It tells you what the problem is, it’s permissions on the private key, try this;
sudo chmod 640 /etc/ssh/ssh_host_ssh_host_ecdsa_key
Or your suggestion of uninstalling, removing the folder and reinstalling would work. Agree though, since you’ve seen two different issues already then there may be more issues you’ve not seen yet.
reconfigured ssh - now everything seems to be up and running!
1 Like
Some final thoughts about this:
- The procedure is working in general but it is really a bit clumsy for the vero.
- Would it be possible to compress the backup already when it is written (create filesystem.tar.xz instead of folder structure)
- Wouldn’t it be a possible to write the backup directly to some kind of image (img or whatever) in order to keep file permissions and uid’s ?
I don’t really understand the question.
A tarball preserves permissions already.
If your goal is to preserve customisations like installed packages (via apt-get for example); then something like Ansible is a better way. It will also allow you to migrate to new devices in the future but preserve your environment.
at the moment the backup-script copies the files to a destination drive (and does NOT tar them), so file-permissions are probably already messed up when they are written to that drive (as they were in my case).
the tarball is created by the restore-script (!).
If your goal is to preserve customisations like installed packages (via apt-get for example); then something like Ansible is a better way. It will also allow you to migrate to new devices in the future but preserve your environment.
its not only about installed packages, but also about their configuration, the fstab file, cron etc. etc. (i think it is not needed to explain the necessity of a fully system backup).
cheers
bendsch
This is something that I would automate – it will greatly make it easier to set up new / identical environments in the future.
Sam
1 Like
No. Permissions are preserved. I don’t understand why they got messed up with your set-up.
Then the whole idea of incremental backups is lost and you end up using a lot more space on the back-up medium if you want to keep multiple back-ups (as I do). Also, it would take a lot longer to do the backup and increase the risk of an inconsistent file tree.
I would prefer to tweak the install kernel so that it can deal with an uncompressed tar, depending on the tarball extension. Then you can just copy the filesystem uncompressed to the SD card/USB and save the lengthy compressing stage.
oh yes, of course - i did not think about it, but incrementality is clearly indispensable.
i still wonder why some file-permissions got messed up. i am using and EXT3 filsystem over NFS. is there another way to make the preserving of permissions more reliable?
I also wonder if there is a way to check if the permissions of other files on the system are right. things seem to be working at the moment, but as jb2cool pointed out: there may be other issues i have not seen yet.
I’m back home, now, and just checked permissions for sudo in all my backups and there is no problem with them (ext4 volume, most via nfs). If it’s the setuid bit that’s the problem, you could unzip the install image and have a look through, eg:
osmc@vero4tv:/mnt/1Text4/vero4tvbackup/2019-04-10/system/usr/bin$ ls -l | grep '^\S*s'
-rwxr-sr-x 7 root shadow 45552 May 17 2017 chage
-rwsr-xr-x 7 root root 36180 May 17 2017 chfn
-rwsr-xr-x 7 root root 27308 May 17 2017 chsh
-rwxr-sr-x 7 root crontab 26748 Oct 7 2017 crontab
-rwxr-sr-x 7 root shadow 13912 May 17 2017 expiry
-rwsr-xr-x 7 root root 49580 May 17 2017 gpasswd
-rwsr-xr-x 7 root root 26756 May 17 2017 newgrp
-rwsr-xr-x 7 root root 37408 May 17 2017 passwd
-rwsr-xr-x 7 root root 18348 Dec 6 17:38 pkexec
-rwxr-sr-x 7 root ssh 321132 Aug 21 2018 ssh-agent
-rwsr-xr-x 7 root root 102612 Jun 5 2017 sudo
-rwxr-sr-x 7 root tty 18312 Mar 7 2018 wall
osmc@vero4tv:/mnt/1Text4/vero4tvbackup/2019-04-10/system/bin$ ls -l | grep '^\S*s'
-rwsr-sr-x 7 root root 519512 Apr 26 2017 busybox
-rwsr-xr-x 7 root root 26120 Aug 21 2018 fusermount
-rwsr-xr-x 7 root root 30832 Mar 7 2018 mount
-rwsr-xr-x 7 root root 91980 Feb 26 2017 ntfs-3g
-rwsr-xr-x 7 root root 30968 May 17 2017 su
-rwsr-xr-x 7 root root 22492 Mar 7 2018 umount
To check all the permissions, you could spend some time with the rsync manual, ie check for changed permissions only and do a verbose dry run to list files with different permissions.
ok, this looks exactly like your backup. so i assume the system is in a normal state …
osmc@B2VERO:/mnt/b2nas/osmc-dd/B2VERO/2019-03-02/system/usr/bin$ ls -l | grep ‘^\S*s’
-rwxr-sr-x 1 root shadow 45552 Mai 17 2017 chage
-rwsr-xr-x 1 root root 36180 Mai 17 2017 chfn
-rwsr-xr-x 1 root root 27308 Mai 17 2017 chsh
-rwxr-sr-x 1 root crontab 26748 Okt 7 2017 crontab
-rwxr-sr-x 1 root shadow 13912 Mai 17 2017 expiry
-rwsr-xr-x 1 root root 49580 Mai 17 2017 gpasswd
-rwsr-xr-x 1 root root 37408 Mai 17 2017 passwd
-rwsr-xr-x 1 root root 18348 Dez 6 18:38 pkexec
-rwxr-sr-x 1 root ssh 321132 Feb 8 15:25 ssh-agent
-rwsrwxrwx 1 root root 102612 Jun 5 2017 sudo
-rwxr-sr-x 1 root tty 18312 Mär 7 2018 wallosmc@B2VERO : /mnt/b2nas/osmc-dd/B2VERO/2019-03-02/system/bin$ ls -l | grep ‘^\S*s’
-rwsr-sr-x 1 root root 519512 Apr 26 2017 busybox
-rwsr-xr-x 1 root root 26120 Aug 21 2018 fusermount
-rwsr-xr-x 1 root root 30832 Mär 7 2018 mount
-rwsr-xr-x 1 root root 91980 Feb 26 2017 ntfs-3g
-rwsr-xr-x 1 root root 30968 Mai 17 2017 su
-rwsr-xr-x 1 root root 22492 Mär 7 2018 umount
How odd that only sudo got borked.
probably ssh-agent got messed up as well. as explained above i had to completely reinstall and configure it.
if it’s just the these two things i have to manually adapt on restore i can live with it …
cheers and thanx for the great support!
bendsch
I don’t think so - it’s OK on your back-up. Only sudo somehow acquired write permissions and lost its setuid.
Your original fail with the restore script: were you trying to write to an SD card in a card reader (ie was the target mmcblk??? rather than sd??). I added code to fix that a while ago but forgot to push it to the git. Version 0.1.7 of osmc-restore works better.
i think it was mmcblk
jfyi: Put out my old Vero2, updated to OSMC 2018.12-1 and used Graham’s actual scripts from github to create backups and restore them using several different sized SD-cards:
Works like a charm!
I placed the file kernel.img from the last Vero2 disk image OSMC 2018.12.-1 into the backup folder you have to mention using the osmc-backup script. The osmc-restore automatically picked that file as well and placed it together with the filesystem.tar.xz onto the SD card. There was no need to use the toothpick method or even I was forced to rename the kernel.img file.
So, this can’t be a class/general issue with the backup scripts. The installer log in the beginning of @bendsch’s posts clearly states the tar file was corrupt which could have various root causes from defect SD card till a manual copy of the file to a too small FAT16/32 partition on the card … who knows. 
From my point of view … can’t dup.
1 Like