[Solved] Backup in another pc in the same network

ghezzia · 25 January 2022 21:28

this is what I can see in the /etc/exports on the server:

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
/mnt/dietpibkp 192.168.1.15(rw,sync,no_subtree_check)
#

Joulinar · 26 January 2022 09:15

slowly I’m running out of ideas. Can you share again df -h

Maybe we need a fresh pair of eyes. MichaIng could you have a look pls. OP is trying to mount a NFS from Ubuntu desktop to DietPi. Somehow he is struggling with write permission

ghezzia · 26 January 2022 10:16

I know that I’m the special one who has the worst use case…
This is the output required on dietpi:

Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.4G  3.4G  3.7G  49% /
devtmpfs         87M     0   87M   0% /dev
tmpfs           215M  5.5M  210M   3% /dev/shm
tmpfs            86M   11M   76M  13% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           1.0G     0  1.0G   0% /tmp
tmpfs            50M   20K   50M   1% /var/log
/dev/mmcblk0p1  127M   52M   75M  42% /boot
/dev/sda1       916G  3.7G  913G   1% /mnt/ownclouddrive
/dev/sdb1       7.3G  3.6G  3.7G  49% /mnt/backup
192.168.1.96:/  457G  238G  197G  55% /mnt/nfs_client

I hope to solve it… It’s one of principle

Joulinar · 26 January 2022 10:25

the NFS mount is still incorrect

192.168.1.96:/  457G  238G  197G  55% /mnt/nfs_client

I thought we already changed this https://dietpi.com/forum/t/solved-backup-in-another-pc-in-the-same-network/6189/26

ghezzia · 26 January 2022 14:24

I went back step by step and the file wasn’t modified. Now it should.
I gave again this command df -hand the output now is:

root@DietPi:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root       7.4G  3.4G  3.7G  49% /
devtmpfs         87M     0   87M   0% /dev
tmpfs           215M  2.4M  213M   2% /dev/shm
tmpfs            86M  2.9M   84M   4% /run
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs            50M  8.0K   50M   1% /var/log
tmpfs           1.0G     0  1.0G   0% /tmp
/dev/mmcblk0p1  127M   52M   75M  42% /boot
/dev/sda1       916G  3.7G  913G   1% /mnt/ownclouddrive

Looks like the server is disappeared. isn’t it?

Joulinar · 26 January 2022 14:41

Try to access the share

cd /mnt/nfs_client
df -h

How does it looks like?

ghezzia · 26 January 2022 17:14

looks like it os there

cd /mnt/nfs_client
root@DietPi:/mnt/nfs_client# df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/root                    7.4G  3.4G  3.7G  49% /
devtmpfs                      87M     0   87M   0% /dev
tmpfs                        215M  2.5M  213M   2% /dev/shm
tmpfs                         86M  5.0M   81M   6% /run
tmpfs                        5.0M     0  5.0M   0% /run/lock
tmpfs                         50M   24K   50M   1% /var/log
tmpfs                        1.0G     0  1.0G   0% /tmp
/dev/mmcblk0p1               127M   52M   75M  42% /boot
/dev/sda1                    916G  3.7G  913G   1% /mnt/ownclouddrive
192.168.1.96:/mnt/dietpibkp  457G  238G  197G  55% /mnt/nfs_client

isn’t it?
should I mount it in a special way?

Joulinar · 26 January 2022 18:01

No special mount needed. The share will be automatically mounted as soon as a process is going to access it.

Could you try to perform following test again

cd /mnt/nfs_client
df -h
touch demo.file
ls -la

ghezzia · 26 January 2022 18:38

Done:

 root@DietPi:~# cd /mnt/nfs_client
root@DietPi:/mnt/nfs_client# df -h
Filesystem                   Size  Used Avail Use% Mounted on
/dev/root                    7.4G  3.4G  3.7G  49% /
devtmpfs                      87M     0   87M   0% /dev
tmpfs                        215M  2.5M  213M   2% /dev/shm
tmpfs                         86M  7.2M   79M   9% /run
tmpfs                        5.0M     0  5.0M   0% /run/lock
tmpfs                         50M   20K   50M   1% /var/log
tmpfs                        1.0G     0  1.0G   0% /tmp
/dev/mmcblk0p1               127M   52M   75M  42% /boot
/dev/sda1                    916G  3.7G  913G   1% /mnt/ownclouddrive
192.168.1.96:/mnt/dietpibkp  457G  238G  197G  55% /mnt/nfs_client
root@DietPi:/mnt/nfs_client# touch demo.file
root@DietPi:/mnt/nfs_client# ls -la
total 12
drwxrwxrwx 3 root   root    4096 Jan 21 18:45 .
drwxr-xr-x 9 root   root    4096 Jan 22 15:58 ..
-rw-r--r-- 1 nobody nogroup    0 Jan 26 19:36 demo.file
drwxr-xr-x 4 nobody nogroup 4096 Jan 21 23:38 dietpi-backup
root@DietPi:/mnt/nfs_client#

MichaIng · 26 January 2022 20:37

So it works now?

If not, I’m not 100% sure about the effect, but probably you need to define the fsid in /etc/exports for NFSv4, fsid=0 is the root of all exported filesystems, so should be right when you export one only. Probably client side the path then needs to be skipped, i.e. 192.168.1.96:/ instead of 192.168.1.96:/mnt/dietpibkp.

ghezzia · 26 January 2022 22:16

I still haven’t try to launch the backup. I’ve not understand if I have to mount the server’s “drive” or not. Do I have to launch it choosing the right “drive”?
Waiting for further suggestions

Jappe · 26 January 2022 22:24

I also had an eye into a documentation how to setup NFS for backup over network (How To Set Up an NFS Mount on Ubuntu 18.04 | DigitalOcean)
and they say:

NFS will translate any root operations on the client to the nobody:nogroup credentials as a security measure. Therefore, we need to change the directory ownership to match those credentials.

sudo chown nobody:nogroup /var/nfs/general

>
>
> You’re now ready to export this directory.

To deactivate this security feature (what probably causes your permission errors), you have to use the "no_root_squash" share option at your host:

So my try would be on the host machine:

```text
sudo chown nobody:nogroup /mnt/dietpibkp
sudo nano /etc/exports

add in “the no_root_squash” for:

/mnt/dietpibkp 192.168.1.15(rw,sync,no_root_squash,no_subtree_check)

Jappe · 26 January 2022 23:02

You wrote in the fstab when it mounts (noauto,x-systemd.automount), so it only mounts when the backup is triggered, I guess)

So for better overiew, I make summary
IP of your Pi: 192.168.1.15
IP of Ubuntu Host: 192.168.1.96

On your host machine, you made the folder “/mnt/dietpibkp” which sould be the backup location.
You give this folder right permissions for NFS:

sudo chown nobody:nogroup /mnt/dietpibkp

Now you make this folder accessable via NFS. You did this by editing /etc/exports

/mnt/dietpibkp 192.168.1.15(rw,sync,no_root_squash,no_subtree_check)

So you give the Pi (192.168.1.15) access to the folder /mnt/dietpibkp with read write permissions and some other options,which you can check out in the link below.

the missing “no_root_squash” in your config could be your permission problem, look here at Step 3 for more information: How To Set Up an NFS Mount on Ubuntu 18.04 | DigitalOcean

Than you made a mount point on the DietPi, which is /mnt/nfs_client
you can manually mount this, but this would be a pain in the ass to do this before every backup, so you made an entry in the fstab:

sudo nano /etc/fstab
192.168.1.96:/mnt/dietpibkp /mnt/nfs_client nfs nofail,noauto,x-systemd.automount

(And this is the good thing about NFS: it mounts itself when the backup is triggered. This is a very safe way, it’s only mounted when needed. You don’t have to do anything.)

Reboot and have a look at

sudo dietpi-drive_manager

Can you see /mnt/nfs_client ?
Don’t try do add your NFS share with the driver manager, bc Joulinar said some days ago:

DietPi Drive manager is not mounting the NFS export correctly. At the moment it is not able to mount sub folder

Now you want to config you backup at your DietPi with

sudo dietpi-backup

Check if the backup location is right

/mnt/nfs_client

and then try to run the backup.

Good luck

Joulinar · 27 January 2022 09:19

this sum it up pretty much. Indeed the missing no_root_squash is a good hint

ghezzia · 27 January 2022 17:28

mmmm I followed step by step all the suggestions. I even add the no_root_squash missed.

I can see the /mnt/nfs_client but the location of the backup (when I open de backup manager) is /mnt/nfs_client/dietpi-backup Is this correct?

I tried anyway to launch the backup but still, a lot of failed: Operation not permitted (1) and deleting usr/lib/modules/5.10.63-v7+/kernel/…ko rows appear.

I saw the above guide and it’s very well done. I would try to follow it but I’m afraid to make a mass since e I have already done randomly some of those steps…

Joulinar · 27 January 2022 19:01

/mnt/nfs_client/dietpi-backup is totally fine as it is the backup folder located inside /mnt/nfs_client/

Is /mnt/nfs_client/dietpi-backup already present in client side?
On server side it should be /mnt/dietpibkp/dietpi-backup

Jappe · 27 January 2022 19:03

This should be the right path.
I have no idea what this “deleting” message is about.

I also tried to backup to a NFs share and it worked for me, but I had a typo which broke the whole thing.
Make sure in

/etc/exports

there is no space between the IP of the client and the (rw)

WRONG:

/mnt/dietpibkp 192.168.1.15 (rw,sync,no_root_squash,no_subtree_check)

RIGHT:

/mnt/dietpibkp 192.168.1.15(rw,sync,no_root_squash,no_subtree_check)

Joulinar · 27 January 2022 19:07

I have no idea what this “deleting” message is about.

DietPi backup is an incremental one. If you already have a backup and files have been removed in source side, they will be deleted on the backup folder as well

ghezzia · 27 January 2022 19:57

there is no space between the IP of the client and the (rw)

I’m afraid there is no space there…
what do you think are all this failed: Operation not permitted (1) rows?
Does it mean the backup is not working?

Joulinar · 27 January 2022 20:30

the backup has no permission to change files on target. It is still a permission issue on your configuration