rsync over ssh errors

[raccoonstrait]

Hello Everyone:

I am trying to set up rsync over ssh from my Xubuntu 20.04.2 system to a Raspberry Pi OS system (new install and updated). The ssh works fine. I have done rsync on the Pi, and know that that works. I tried to get rsync over SMB to work, but while it seemed to work, the results were not satisfactory. So now I am trying rsync over ssh. The drives are mounted via FSTAB to /home/public/user/DRIVES/ on both systems. These are multi terabyte external drives mounted via USB. Here is what I get.

rsync -rogvP --delete --ignore-existing --size-only --partial -s /home/public/users/MyDrive01/ pi@IPAddress:/home/public/users/5TBMyDrive01-BU
pi@IPAddress's password: 
sending incremental file list
rsync: change_dir "/home/public/users/MyDrive01" failed: No such file or directory (2)


sent 24 bytes  received 12 bytes  2.88 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1207) [sender=3.1.3]

I have tried a number of options sets. I have also tried a number of rsync configurations, following different recommendations from various websites after searching for the error statements. I have even added the source drives (the ones rsync seems to be complaining about) to my path. No joy.

Is this merely a syntax error, or am I missing something completely?

Thanks

Raccoon Strait

[HermanAB]

Well, the error message is very explicit!
At the exact point in time when rsync runs, the source directory is not accessible.

[raccoonstrait]

Thanks for the response HermanAB,

That's the thing though. The source directory is part of a Samba NAS and has no trouble serving that function. The source directory is accessible to file managers, and even remote machines over SMB. I even exited ssh and changed the current directory to the root of the source in Bash and then tried ssh and rsync again. That error message was captured when the current directory was the source directory that rsync is telling me it can't access. And this went on for several hours as I searched for possible answers.

I suppose I should add that if I move the target drive to the source machine, rsync runs without issue.

Why would that be?

Raccoon Strait

[HermanAB]

So you are running rsync over ssh over samba? Layer it three deep is just looking for trouble. If you remove either samba or ssh, then it will probably work much better.

[raccoonstrait]

Well, I had tried that, rsync over Samba, from the target system, and I got a lot of errors. Just now, I tried again from the source system. Rsync had issues with retaining permissions and there were a number of files that reported 'permission denied (13)'. All the devices have had chown nobody:nogroup both with and without the -R as well as chmod 777, again both with and without the -R. Some of the permission denied files are new, but many that have been overwritten recently are not denied. I was hoping the ssh method would alleviate that issue.This is similar behavior that took place when running rsync over SMB from the target system. It doesn't seem right, and that is why I tried to do it using ssh.

If you note the ssh/rsync command I used in my original post, there is no SMB mentioned, which to me means the Samba was removed from the equation. Or is that fact that samba is running at all the problem?

When running rsync strictly over SMB the path looks like this:

rsync: recv_generator: failed to stat "/run/user/1000/gvfs/smb-share:server=raspberrypi.local,share=public/5TBMydrive01-BU/Programs/series/season/filename": Permission denied (13)

smb is definitely involved there.

So, I am back to my original issue, I think.

Thanks

Raccoon Strait

[TheFu]

rsync over SMB? That's confusing.
How about "rsync to an SMB mount"?
Just mount the SMB/CIFS to the machine where the files are located and use rsync. That works. I use it a few times a week.

Oh ... and don't use a GUI to mount samba/CIFS storage. Setup the CIFS mount in the /etc/fstab or by using autofs if you want this to work.

gvfs won't work. That's the problem.

[raccoonstrait]

Thanks for your input TheFu

Here is how all of these drives are mounted via fstab, on both systems. I did have a statement at the end x-gvfs-show which I have now removed, could that have been the problem? I was already using auto for the fs, the drives are all ext4.

LABEL=5TBMydrive01 /home/public/users/5TBMydrive01 auto rw,nofail,noatime 0 2

Is this the correct mounting?

Raccoon Strait

[TheFu]

If you type

df -Th

Does all the storage involved show up? Both the source and the target? If not, no, that is not correct.

I've never used "auto" for the file system type. The actual type is very important. Other options maybe needed, but i cannot tell.

[raccoonstrait]

No, only the local drives show up using df.

I have just tried to rsync using the path shown in Thunar for the remote drive, no help as it doesn't seem to like the smb// and removing the smb didn't help either.

I am going to try to change all the mounts from auto to ext4 and see if that helps.

Raccoon Strait

[HermanAB]

If df doesn't show the mounted file system, then it is not mounted.

Once mounted, the remote filesystem directory works the same as a local filesystem directory, so then you don't need a smb:// anymore.

The upper layer tool can't work if the lower network layer is broken.