backup destination to internal media

Hardware Little Backup Box
1

I have followed the instructions in the ebook for enabling internal storage.

however, it is not working.

from a fresh boot up, I invoke Card Backup from the remote control, and then insert a card. The card reader blinks a few times. The status light on the pi does not change. No files are copied from the card to /home/pi/BACKUP.

It appears the card is not mounting:
blkid -o list
device fs_type label mount point UUID
-------------------------------------------------------------------------------
/dev/mmcblk0p1
vfat boot /boot AF14-47C0
/dev/mmcblk0p2
ext4 rootfs / b57a7299-0677-4dc6-b4b0-c10f107f0f6d
/dev/ram0 (not mounted)
/dev/ram1 (not mounted)
/dev/ram2 (not mounted)
/dev/ram3 (not mounted)
/dev/ram4 (not mounted)
/dev/ram5 (not mounted)
/dev/ram6 (not mounted)
/dev/ram7 (not mounted)
/dev/ram8 (not mounted)
/dev/ram9 (not mounted)
/dev/ram10 (not mounted)
/dev/ram11 (not mounted)
/dev/ram12 (not mounted)
/dev/ram13 (not mounted)
/dev/ram14 (not mounted)
/dev/ram15 (not mounted)
/dev/mmcblk0
(not mounted)
/dev/sda1 (not mounted)

/dev/sda1 is the camera card. If I manually mount it, I can see the files, but it does not run the script.

My config.cfg looks like:
STORAGE_DEV=“sda1” # Name of the storage device
STORAGE_MOUNT_POINT="/media/storage" # Mount point of the storage device
CARD_DEV=“sdb1” # Name of the storage card
CARD_MOUNT_POINT="/media/card" # Mount point of the storage card
BAK_DIR="/home/pi/BACKUP" # Home directory path
SHUTD=“5” # Minutes to wait before shutdown due to inactivity
INTERNAL=true # Set to true to enable internal storage as backup destination
# With internal storage option enabled,
# modify the STORAGE_DEV and CARD_DEV values
SYNCTHING=true # Set to true to enable Syncthing

Per instructions in the book, storage should be sda1 and card should be sdb1, but shouldn’t the card be sda1 when there is no external storage? (and how does the card backup script know to not wait for the storage to mount?)

2

Welcome to PIXLS.US! :slight_smile:

I think I made a mistake in the book. The value of the STORAGE_DEV parameter should be /dev/mmcblk0p2 It would be really great if you have a chance to to try this out and report back.

Thanks!

Best,
Dmitri

3

Ill try that when I get home in a few hours.

Should the card remain /dev/sdb1 or should it be changed to /dev/sda1 as it will be the first device to mount?

4

The answer is to change both, card needs to be /dev/sda1 to mount

STORAGE_DEV="/dev/mmcblk0p2" # Name of the storage device
STORAGE_MOUNT_POINT="/media/storage" # Mount point of the storage device
CARD_DEV="sda1" # Name of the storage card
CARD_MOUNT_POINT="/media/card" # Mount point of the storage card
BAK_DIR="/home/pi/BACKUP" # Home directory path
SHUTD="5" # Minutes to wait before shutdown due to inactivity
INTERNAL=true # Set to true to enable internal storage as backup destination
# With internal storage option enabled,
# modify the STORAGE_DEV and CARD_DEV values
SYNCTHING=true # Set to true to enable Syncthing

However, now the SMB mount point is locked for guest access. It doesn’t let me login as the pi user. chmod 777 does not allow access either.

Closer, but not there yet

1 Like
5

chown and chgrp from root to pi does not solve it either

6

OK, I see the problem. The Card-backup script is creating/copying everything as root. Not a problem to an exfat card as permissions get ignored there. But on internal media… it matters

7

Thank you so much for following up on this! I’ll update the instructions, and I’ll try to find a way to fix the issues.

8

Thinking out loud. What if we replace this in the card-backup.sh script:

if [ "$INTERNAL" = true ]; then
    STORAGE_MOUNT_POINT="$BAK_DIR"
    mkdir -p "$STORAGE_MOUNT_POINT"
else

with this

if [ "$INTERNAL" = true ]; then
    STORAGE_MOUNT_POINT="$BAK_DIR"
    mkdir -p "$STORAGE_MOUNT_POINT"
    chown pi:users -R "$STORAGE_MOUNT_POINT"
else

I probably won’t have time to do anything Little Backup Box-related in the coming days, but I’ll be keeping an eye on this thread.

9

Nope. that does not do it. I think it is more than posix permissions.

pi@backupbox : ~ $ ls -l BACKUP/
total 16
drwxr-xr-x 5 pi root 4096 Dec 31 1969 201907311036-5034
drwxr-xr-x 2 root users 4096 Jul 31 17:35 roottest
drwxr-xr-x 2 pi users 4096 Jul 31 17:34 test
drwxrwxrwx 2 pi users 4096 Jul 31 17:05 untitled folder

Interestingly, I did a sudo mkdir roottest and the created directory is owned by root, however, SMB guest access can read and write to it. But not the card backup folder. Also note the created date of the card backup folder

I tried adding

mkdir “$STORAGE_MOUNT_POINT”/scripttest

right before the rsync command in the card backup script and it created a directory that is owned by pi and group root. It is read and write capable in SMB. So it isn’t the script specifically doing it.

Still poking at it

10

OK, so I decided to re-implement the internal backup feature to make it less error prone and easier to use. I pushed the changes to the experimental branch. You can switch to it running the following commands in the little-backup-box cloned repository:

git fetch --all
git checkout experimental

Start then the web UI, press the Internal backup button, and insert a storage card.

12

I don’t know what that means.

pi@backupbox : ~ $ git fetch --all
fatal: Not a git repository (or any of the parent directories): .git

13

Also, I have confirmed this is a Samba issue. SFTP works fine on the same directory.

14

I managed to finish a complete rewrite of the internal back feature. I tested it briefly, and it seems to work. Samba and DLNA should also work.

I recommend to install the new version from scratch on a clean system.

15

OK, installed the new version on a clean system install. It does indeed backup the card into a directory called “storage” which is served by Samba. It is not accessible via Samba. It is accessible via SFTP. Same issue as the previous incarnations but in a different directory.

pi@backupbox : ~/BACKUP $ ls -l
total 4
drwxr-xr-x 5 root root 4096 Dec 31 1969 storage

16

Looking at the code, I realized that Samba login credentials are pi (username) and raspberry (password). I’ll do more testing when I have a chance.

17

OK, I have found the actual problem with Samba sharing, and a bandaid solution.

(for those finding this thread: Samba is a reverse-engineered copy of windows file sharing bolted onto Linux, and it works about as well as you would expect. )

The actual (symptom of the) problem is the created date of ~/BACKUP/storage, which shows as Dec 31, 1969. I suspect that simply means it has no created date. (previously, the same thing occurred to the directory named [date]-[card id] )

Having no or an invalid date apparently breaks Samba’s permissions structure in some weird and fundamental way.

Simply touching the directory with a valid data (any valid date) alleviates the issue:

sudo touch -t 1908060000.00 /home/pi/BACKUP/storage/

So, the part of the script that creates ~/BACKUP/storage (though not the part that creates BACKUP itself) is what needs to be fixed or bandaged so that the directory has a valid created date.

in card-backup.sh you use:

touch $(date -d “today” + “%Y%m%d%H%M” )- $random .id

to create the card UUID. Apparently in later versions of Linux touch -d only modifies the date of files, not of directories, so if you are using the same method to create the directory in ~/BACKUP, changing it to touch -t may fix the whole issue. I don’t see how internal-backup creates the directory. (or is Rsync creating it?)

I edited the internal-backup script to add:

sudo touch -t 1908060000.00 /home/pi/BACKUP/storage

after rsync and that fixed it, though that seems like a kludge. I could not get

sudo touch -t 1908060000.00 “$BAK_DIR”

to work at all. Not understanding why

I am also assuming that the production version will once again create directories in the [DATE-CARDID] name format so that we may backup up multiple cards.

Looking at the code, I realized that Samba login credentials are pi (username) and raspberry (password)

I see that as a pretty significant issue. I always change the password of the Pi user as a best practice when initially setting up the pi (prior to installing anything, along with localization)

May I suggest from a UX standpoint that the install script has an interrupt that asks for a password for Samba-user Pi (pre fill “raspberry” if you like). A mismatch between system user passwords and Samba user passwords is likely to be a problem (it’s not this problem, I spent a while eliminating that as an issue).

Also from a UX standpoint, asking the user to choose between internal and USB storage during the install might be the simple way to go, as there seems to be no way as it stands to backup to internal media if you want to not have remote control (like the classic LBB functionality). As I see it, the choice between internal and USB is going to be hardware driven and would not change in the field (though I could see a case for it). In my case, I would use internal if using a PiZeroW with large MicroSD card and only one USB port available (though I would want remote control so I could turn sharing and syncthing on and off at need)

I would also be perfectly happy with rolling back to the previous shipping version and just updating the instructions to set an internal backup destination:

STORAGE_DEV=“/dev/mmcblk0p2” # Name of the storage device
CARD_DEV=“sda1” # Name of the storage card
INTERNAL=true # Set to true to enable internal storage as backup destination

Hopefully I haven’t put too much information in this reply

1 Like
18

It works really well and has for a long time…

19

I see that as a pretty significant issue. I always change the password of the Pi user as a best practice when initially setting up the pi (prior to installing anything, along with localization)

Shouldn’t be an issue at all, since the installer script configures Samba shares to be accessible by guests. Also, imagine you have no idea what Samba is, and in the middle of the installation process you are asked to provide a Samba password. I think this will more confusing than helpful.

Also from a UX standpoint, asking the user to choose between internal and USB storage during the install might be the simple way to go, as there seems to be no way as it stands to backup to internal media if you want to not have remote control (like the classic LBB functionality).

Good idea! I’ve already implemented it. Now you can select the Internal backup mode during installation.

I couldn’t replicate the Samba share access issue. It worked as expected for me. But to be on the safe side, I’ve added the workaround you described to the installer script.

Once again, thank you very much for your detailed feedback!

20

I’ll make a test build this afternoon and report back.

Also, imagine you have no idea what Samba is, and in the middle of the installation process you are asked to provide a Samba password. I think this will more confusing than helpful.

Sadly, good security is always confusing to those who need it the most :wink:

since the installer script configures Samba shares to be accessible by guests.

Also a terrible idea, and will (rightfully) fail any security audit. (not that these boxen will ever get audited). I need to learn more about how to configure Samba and alter my builds to be more secure. Still, it’s your project, I’ll let it go.

I couldn’t replicate the Samba share access issue. It worked as expected for me. But to be on the safe side, I’ve added the workaround you described to the installer script.

I wonder if it is because I am accessing Samba shares from a Mac. I tracked down the issue from reports from Windows users having the same issue. Might be some stupidity shared by MacOS and Windows that is causing it to fail, and Linux to Linux sharing doesn’t trigger it. (me: making the large assumption that you don’t test from MacOS or Windows. To be fair, I don’t test from Windows)

Once again, thank you very much for your detailed feedback!

You re most welcome, thats for creating this!

21

In theory, yes. But in practice this is not such a big deal. Only a single empty directory has guest access, and even if the Raspberry Pi running Little Backup Box is connected to a network, it’s likely to be powered for a limited period of time. But point taken. I’ll add a warning that the installer creates a publicly accessible Samba share.