rsync over ssh errors

[raccoonstrait]

OK guys, I think I see some light in this tunnel. Mounting the remote drive to a local directory is the key (one I had not heard of before). And, when done it does show up in thd df -TH.

For those who are interested this seems to work, but prepare the local directory first.

sudo sshfs -o allow_other pi@IPAddress:/home/public/users/5TBMydrive01-BU /home/username/Backup-Temp/

Even though I did not get the original issue solved, I did get a working solution.

Thank you guys.

Raccoon Strait

[TheFu]

sshfs is really slow. Best to be used for temporary stuff or over the internet.
Either use nfs or cifs when on the same LAN. Both will be 2-4x faster than using sshfs.

[raccoonstrait]

Thanks TheFu,

It took a while to configure the cifs mount, but I finally got it.

The drives are all mounted on /home/public/users/Drivename, on both systems but the remote drives have -BU appended to their name.
The local directories were created in advance.
All files/directories are owned by nobody:nogroup which is what the number 65534 represents.
All the files have been treated with sudo chmod 777
I tried to mount //IPAddress/5TBMyDrive but that failed, I needed to include the /public/, as seen below

Here is the fstab command that worked

//192.168.11.115/public/5TBSeagate01-BU/  /home/raccoon/Backup-Temp-01 cifs rw,guest,noperm,_netdev,credentials=/etc/samba/.cifscreds,iocharset=utf8,file_mode=0777,dir_mode=0777,uid=65534,gid=65534,nofail 0 0

All the options were gleaned from various websites in trying to get this to work. Some of them may not be necessary.

These drives now mount at reboot or with sudo mount -a.

Thanks again

Raccoon Strait

[TheFu]

Good job on getting something working. With so many moving parts, this can be confusing.

You might find my post here: https://ubuntuforums.org/showthread....3#post14024193 with explanation to be helpful.

• chmod doesn't work with cifs mounted storage. If you want chmod to work, use NFS. NFS is preferred for a number of reasons. One of those is that native owners, groups, permissions, ACLs and often xattrs are supported, unlike the back-o-da-bus CIFS.
• Mounting storage under an existing HOME is a poor choice for a number of reasons. You can trust me now or learn those reasons when it happens to you.
• Almost always, setting permissions to 777 is a terrible idea. I think it is in this situation too. It makes for non-secure situation and provides anyone who can claim to be the client able to delete all the files. That's always a bad idea.
• uid=65534,gid=65534 are useless. No need to specify either, if you use 777. If you have just 1 userid, set that (the name or the numeric id can be used). If you have multiple userids that you want to provide access, use that after you put all the client-side users into a shared group together. Use the 'id' command to get numbers.
• guest doesn't mean the same thing on the client site as it does in Windows. I doubt you want that - if you do, then you shouldn't need any credentials=.

That's probably enough. Ignore whatever you like.

[raccoonstrait]

Advise taken. Local directories moved to /mnt/Backup-Temp-01, and etc.

The fstab now looks like this:

//IPAddress/public/5TBMydrive01-BU  /mnt/Backup-Temp-01 cifs rw,noperm,_netdev,credentials=/etc/samba/.cifscreds,iocharset=utf8,uid=1000,gid=1000,nofail 0 0

Thanks for the feedback.

Raccoon Strait

[TheFu]

I'm guessing there's no convincing you to use NFS? I had to ask.

[raccoonstrait]

I loves me a challenge, so I have tried NSF, and was mostly successful.

I can mount the remote drives manually using:

sudo mount 192.168.11.115:/home/public/users/5TBMydrive01-BU /mnt/Backup-Temp-01 && sudo mount 192.168.11.115:/home/public/users/5TBMydrive02-BU /mnt/Backup-Temp-02 && sudo mount 192.168.11.115:/home/public/users/5TBMydrive03-BU /mnt/Backup-Temp-03 && sudo mount 192.168.11.115:/home/public/users/BU-Hosts-BU /mnt/Backup-Temp-Hosts

But when I try to get fstab to do the same thing with sudo mount -a it times out. Here is the latest code tried in fstab though there were several other sets of options at various points.

192.168.11.115:/5TBSeagate01-BU  /mnt/Backup-Temp-01 nfs auto,_netdev,proto=tcp,async 0 0

I will replicate whatever works here to the other shares and uncomment them.

It is a standard domain WORKGROUP and I found a thread where a similar issue was being discussed, but did not find any resolutions, (that person made some change to systemd timeouts, but I have no earthly idea how to go about that).

Any suggestions?

Thanks

Raccoon Strait

BTW, you did say or!

[TheFu]

192.168.11.115:/home/public/users/5TBMydrive01-BU
is not te same as
192.168.11.115:/5TBSeagate01-BU

Is it?

the NFS server /etc/exports file needs to be setup, at least for linux nfs servers. For a commercal NFS, you'll need to find a how-to for that model.

[raccoonstrait]

Dang, I was trying to hide the actual drive names, safety you know. The names are correct where they need to be.

The NFS Server is a Raspberry Pi running Raspberry OS and was setup using info from https://pimylifeup.com/raspberry-pi-nfs/. As I said, the drives mount manually, it is just the fstab I am having difficulty with. I just tested the rsync, for each of the partitions, and it worked (manual mount).

There is a difference between the manual mount and the fstab mount statements, the manual uses the full path, but I removed that for the fstab statement as I was getting different error messages with that, like it didn't recognize it at all. Which should it be, full path or something else? There was that issue where leaving out /public/ for the cifs setup made a difference.

Raccoon Strait

[TheFu]

There is a difference between the manual mount and the fstab mount statements, the manual uses the full path, but I removed that for the fstab statement as I was getting different error messages with that, like it didn't recognize it at all. Which should it be, full path or something else? There was that issue where leaving out /public/ for the cifs setup made a difference.

Well, the source used in the manual mount and in the fstab should be the same. We can't just randomly remove parts and expect it to work.
The /etc/exports file controls what is shared via NFS.

This has nothing to do with CIFS. They aren't related in any way. CIFS sharing is controlled by the smb.conf file. You can have both or one or neither setup. They work differently. A few of my NFS mounts from a client system:

$ df -Th
Filesystem                      Type  Size  Used Avail Use% Mounted on
istar:/d/D1                     nfs4  3.5T  3.5T   44G  99% /d/D1
istar:/d/D3                     nfs4  3.6T  3.6T   15G 100% /d/D3
istar:/d/D2                     nfs4  3.6T  3.5T   29G 100% /d/D2
romulus:/Data/r2                nfs4  1.3T  1.2T   67G  95% /S
romulus:/raid/media             nfs4  1.8T  1.7T  7.7G 100% /R
romulus:/raid/media/Music       nfs4  1.8T  1.7T  7.7G 100% /M

In general, I prefer to have the storage mounted at exactly the same location over NFS as it is mounted on the NFS server. This limits my confusion, since I use lots of different systems. It is good to look in the same place for files. I don't use NFS for any backup storage. That's a safety thing. Wouldn't want to accidentally delete stuff.

Also, for some systems, the NFS mounts are read-only to protect the data. For example, I want Music and photos available via Nextcloud, but I don't trust Nextcloud not to delete everything. That means a read-only mount. I consider Nextcloud to be a high-risk webapp. If someone hacks into that system and decides to be mean by deleting everything - fine. But the read-only data won't be touched as it sits on a different system.