External SSD with urbackup

General Discussion
21

so no solution for NTFS?

22

Did you already tried to format your external disk using drive manager? There is an option to format the whole drive with NTFS file system?

Or as an alternative you could try to do all steps manually.

  1. delete partition How to Delete Partition in Linux {Using the fdisk Utility}
  2. create new partition How to Create Partitions in Linux {Using parted and fdisk Commands}
  3. format partition with NTFS file system How to Format Disk Partitions in Linux {ext4, NTFS and FAT32}
23

So I tried to format the whole drive (sdc) within the drive manager and got an error with exit code 127.

/boot/dietpi/func/dietpi-globals: line 858: mkfs.ntfs: command not found

I try to make it manually.

24

usually this is part of ntfs-3g package, which is installed by drive manager as well. Could be done manually as well

apt install ntfs-3g
25

crazy! I thought about that, but I also thought, that dietpi already has this package. Ok, So I can now format it manually. It seems to last a while.

Try to mount it after that and write with urbackup. Thanks so far!

26

only if needed, itā€™s installed by drive manager automatically while detecting a NTFS drive.

27

as it seems, it did not install in automatically on my raspi.

So my urbackup runs now.
The only problem isā€¦ itā€™s VERY slow. But I make a new thread for that.
Thanks!

28

Hi all, Iā€™m new to DietPi after hearing good things about it in the openHAB Community. So far I really like it, but I struggled to set UrBackup to use my external SSD.

After mounting my SSD, I followed these instructions in the DietPi docs:

image
image1047Ɨ262 21.1 KB

But no matter what I did, chmod would give me an invalid mode error. After learning a bit more about chmod, I realized that I needed to do this:

mkdir /path/to/backup/storage
chmod -R 777 /path/to/backup/storage

This granted read/write/change permissions to all users, and now UrBackup has stopped complaining.

Iā€™m wondering if the docs should be edited to this? I donā€™t see how urbackup:urbackup makes any sense for chmod, unless thatā€™s just something I havenā€™t learned yet.

29

is just an example directory/patch and you would need to replace it with your own backup target location.

You donā€™t need to give everyone write access to the backup target location. Itā€™s enough to enable urbackup user to write backup data into target location.

30

Ah, I wasnā€™t questioning that. I just used the example path since I referenced the screenshot. My actual path was /mnt/crucial/urbackup.

Right, but the command chmod -r urbackup:urbackup /mnt/crucial/urbackup didnā€™t do that. It threw an error and complained that urbackup:urbackup is an invalid mode.

Maybe a better question would be: what is the correct command to give the urbackup user access to the target location? Because the command in the screenshot didnā€™t work.

31

What youā€™ve tried is a mix of the syntax for chown (change ownsership) and chmod (change permissions).
Seems like there is a typo in the docs. I will create a PR for correction.

chmod:

chmod -R 777 /path/to/backup/storage

chown:

chown -R urbackup:urbackup /path/to/backup/storage
2 Likes
32

Thanks, thatā€™s what I thought, but I didnā€™t explain it well.

Is it recommended to also change the ownership to urbackup? I left it as root since 777 granted permissions to all.

EDIT: I get it now after reading the PR. Instead of chmod, it should have been chown to reassign the ownership, while leaving the permissions as they were. So, I think I should do that and then revert the permissions with chmod 744, correct?

33

Depends on your usecase.
But I would own it to urbackup:urbackup, and set 740 permission. So you could add users to the group urbackup, they would be able to read the data and the app itself can do anything and other users canā€™t do nothing.

edit:

Yea just do 744, so you donā€™t need to add any users to groups.

2 Likes