rsync input/output error 5 from Arch, but not from Mint [solved]

bpeary · 2022-02-02 22:52:59

I do a one-way sync to a Widows share, using grsync. This used to work fine from both Arch and Mint (same machine, dual boot). But months ago I started getting this type of error from Arch:

sending incremental file list
Admin/Student Issues 2022a.xls
          9,216 100%    0.00kB/s    0:00:00 (xfr#1, to-chk=540/568)
Admin/attendance 2022a.xls
rsync: [receiver] rename "/run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/Admin/.Student Issues 2022a.xls.6SPth7" -> "Admin/Student Issues 2022a.xls": Input/output error (5)
        266,240 100%    1.04MB/s    0:00:00 (xfr#2, to-chk=535/568)
PPT/06 Variance and Normal Distribution.pptx
rsync: [receiver] rename "/run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/Admin/.attendance 2022a.xls.F5Xt4p" -> "Admin/attendance 2022a.xls": Input/output error (5)
        893,746 100%    1.46MB/s    0:00:00 (xfr#3, to-chk=223/568)
rsync: [receiver] rename "/run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/PPT/.06 Variance and Normal Distribution.pptx.oTzdlL" -> "PPT/06 Variance and Normal Distribution.pptx": Input/output error (5)

sent 1,191,463 bytes  received 104 bytes  140,184.35 bytes/sec
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1330) [sender=v3.2.3]
total size is 214,248,412  speedup is 179.80
Rsync process exit status: 23

For Arch, the versions are rsync 3.2.3-4 and grsync 1.3.0-1. For Mint, the versions are rysnc 3.1.3-6 and grsync 1.2.6-2

The command for Arch (auto-generated by grsync is:

rsync -r -x -v --progress -u -s --exclude *DRAFT* --exclude *draft* --exclude *Draft* --exclude 'Pay Stubs' --exclude z_immutable /data/bruce/Stat301/ /run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/

The command for Mint (auto-generated by grsync) is:

rsync -r -x -v --progress -u -s --exclude *DRAFT* --exclude *draft* --exclude *Draft* --exclude Pay Stubs --exclude z_immutable /data/bruce/Stat301/ /run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/

Anyone see what I'm doing wrong?

Last edited by bpeary (2022-02-21 00:52:02)

seth · 2022-02-03 08:20:04

I suspect the issue is rather w/ cifs/gvfs - can you reliably copy (cp) files to the gvfs mount? (Try larger files)
Can you reliably copy/rsync to a cifs mount?

bpeary · 2022-02-03 14:16:17

Thanks for the reply. Yes I can -- I copied one of the files in the error message, and double-checked that the new information was present in the target, and it was.

seth · 2022-02-03 15:33:48

Can… copy to the gvfs mount or the cifs mount?
The files in the list aren't very big - if this is a network thing, it'll be provoked by a data burst.
Try to copy some large file (100+MB)

bpeary · 2022-02-04 17:36:36

I'm only using gvfs via smbclient.

I created a 109 Gib 7z file to test. If I drag it into the target using Thunar, that works fine. If I open a terminal and issue a cp command, I get permission errors:

cp: preserving permissions for ‘./stat.7z’: Operation not supported

seth · 2022-02-04 20:59:44

Did you "cp -a" or "cp -p"? You cannot preserve permissions via SMB.
smbclient is a 3rd implementation (next to cifs and gvfs)

bpeary · 2022-02-05 17:46:05

That was a 'cp' with no arguments. From the target mount point (target is a Windows server) I opened a terminal and used:

cp /data/filename ./

Trying this again today I see that I made a mistake saying the file didn't copy -- it did copy, and the error was just about the permissions (Windows).

And now, copying that 109 Mb file with the following command, it copies with no errors:

cp --no-preserve=mode /data/stat.7z ./

seth · 2022-02-05 21:57:53

If you hash source and rsync destination, is the rsync io error down to diverging permissions as well or are there different files?

bpeary · 2022-02-08 00:15:51

This is getting beyond my abilities. Do you mean the --checksum option? If so, I get the same error 5. Nothing about permissions.

seth · 2022-02-08 07:03:40

I mean to just run md5sum on source and destination file and see whether they actually differ.- though your rsync command doesn't seek to preserve them (but nor would a plain cp)

Edit: --checksum is a skip strategy and not relevant here

Last edited by seth (2022-02-08 07:04:16)

bpeary · 2022-02-10 00:08:09

They are different:

/run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/Admin> md5sum attendance\ 2022a.xls 
c907acabac10ce75f4656525cd0cdf61  attendance 2022a.xls

 DING! (bp) /run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/Admin> md5sum /data/bruce/Stat301/Admin/attendance\ 2022a.xls 
39562e0a29220a2b9465b5e008e40c58  /data/bruce/Stat301/Admin/attendance 2022a.xls
 7:01pm (bp) /run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/solomonb/current/Admin>

bpeary · 2022-02-10 00:12:13

seth: I appreciate your help and your time, but I'm starting to think it's too much to ask. The sync works as expected in Mint, so I'm not seriously disadvantaged by just using Mint to do this.

seth · 2022-02-10 08:37:48

tbh, I care far less about your situation, but a bug in either rsync or the kernel - which will inevitably hit mint and any other distro once they catch up.
I'm currently down to a borrowed windows system and a (grrr) touchphone (unexpected travel...) but will try cifs copying next week.

If you want to entertain yourself in the meantime, follow the system journal while copying (for IO or network errors) and if you've so far not done that to not copy with the cifs share as $PWD.

bpeary · 2022-02-12 17:56:14

I got it to work with this procedure, but I don't understand it.

I mounted the share via cifs with the following command:

sudo mount -t cifs -o credentials=/home/bp/itap.txt  //myhome.itap.purdue.edu/myhome/solomonb /home/bp/itap

I could neither use rsync with /home/bp/itap (error 13: permission denied), nor drag files into it.

But, and this is the part I don't understand, the target also appeared in the gvfs directory I had previously been using, /run/user/1000/gvfs/smb-share:server=myhome.itap.purdue.edu,share=myhome/0/, and that worked with rsync without error.

seth · 2022-02-12 21:49:55

If you take gvfs and the graphical session out of the equation and mount the cifs share on the console (not even logged into the GUI, ideally just boot the multi-user.target, see 2nd link below) and rsync there: do you still get the same problem?

bpeary · 2022-02-14 23:50:09

I'll try that as soon as I can. This is a very old system (pre-systemd). I always boot into a text console, then run startx. If I simply don't run startx, is that where you want me to be?

seth · 2022-02-15 09:30:10

Yup, exactly.

bpeary · 2022-02-15 22:31:45

No success. Here's what I did:
1. login to console on F1
2. login to second console on F2 and openconnect to the Purdue VPN server
3. back at F1, mount the share with this command:

sudo mount -t cifs -o credentials=/home/bp/itap.txt  //myhome.itap.purdue.edu/myhome/solomonb /home/bp/itap

4. run the following rsync command:

rsync -r -x -v --progress -u -s --exclude *DRAFT* --exclude *draft* --exclude *Draft* --exclude 'Pay Stubs' --exclude z_immutable /data/bruce/Stat301/ /home/bp/itap/current/

rsync: no match. Am I not understanding what the target address should be in the command?
5. using ls, I made sure both the target and source showed what I expected to see -- they did.
6. Another issue is that all the folders and files in /home/bp/itap/current/ are owned by root, and not writable by me.

seth · 2022-02-15 23:36:30

There might simply be nothing to update.

touch /data/bruce/Stat301/dummy.txt

Purdue VPN

Stuff one learns by random chance… ;-)
Try to undercut the MTU to comensate for VPN overhead, eg.

sudo ip link set dev eth0 mtu 1200 # replace eth0 w/ the actual NIC

Another issue is that all the folders and files in /home/bp/itap/current/ are owned by root, and not writable by me.

https://wiki.archlinux.org/title/Samba#Manual_mounting

bpeary · 2022-02-17 10:29:44

I got the cifs mount writable. Had to add uid=1000 to make me the owner:

sudo mount -t cifs -o credentials=/home/bp/itap.txt,uid=1000 //myhome.itap.purdue.edu/myhome/solomonb /home/bp/itap

Now rsync transfers files with no errors to the cifs mount. How does this help us with the original smbclient mount?

V1del · 2022-02-17 10:32:41

Not much, the in kernel cifs support is a completely different implementation from smbclient, so we'd still need to find out what it does differently here.

Last edited by V1del (2022-02-17 10:33:46)

seth · 2022-02-17 12:17:51

The original issue seem to have revolved around gvfs - since we now know that the bug is in that area, I'd next try smbclient by itself and "put" a file onto the share.
As a immediate mitigation, you can simply use cifs mounts instead of gvfs to do the sync - you can even x-systemd.automount the fstab entry to implicitly mount the share when trying to access it.

bpeary · 2022-02-18 12:35:28

Sounds similar to this old issue:

no-write-access-to-gvfs-smb-shares

Arch Linux

#1 2022-02-02 22:52:59

rsync input/output error 5 from Arch, but not from Mint [solved]

#2 2022-02-03 08:20:04

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#3 2022-02-03 14:16:17

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#4 2022-02-03 15:33:48

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#5 2022-02-04 17:36:36

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#6 2022-02-04 20:59:44

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#7 2022-02-05 17:46:05

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#8 2022-02-05 21:57:53

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#9 2022-02-08 00:15:51

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#10 2022-02-08 07:03:40

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#11 2022-02-10 00:08:09

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#12 2022-02-10 00:12:13

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#13 2022-02-10 08:37:48

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#14 2022-02-12 17:56:14

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#15 2022-02-12 21:49:55

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#16 2022-02-14 23:50:09

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#17 2022-02-15 09:30:10

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#18 2022-02-15 22:31:45

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#19 2022-02-15 23:36:30

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#20 2022-02-17 10:29:44

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#21 2022-02-17 10:32:41

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#22 2022-02-17 12:17:51

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

#23 2022-02-18 12:35:28

Re: rsync input/output error 5 from Arch, but not from Mint [solved]

Board footer