rysnc task error

[denningsrogue]

I am using an rsync task to copy files from my FreeNAS to a FreeBSD server. The task ends with the following error:

rsync: IO error encountered -- skipping file deletion

Any ideas as to what the issue might be?

 

[saurav]

Assuming this is on your FreeNAS, under Tasks/Rsync Tasks in the GUI, can you tell us how it is set up? In particular, do you have the checkbox next to "Delete" selected?

 

[denningsrogue]

Your assumption is correct. I have the check box next to delete selected. Here is a screen shot showing the options selected.

 

[saurav]

If you hover over the "i" next to the checkbox, you'd see that "Delete" means rsync will delete those files on the destination that do not exist on the source.

Try unchecking the checkbox next to "Delete" and see if your problem goes away. This should not do you any harm, but will leave some files on the destination that you probably wanted deleted.

By default rsync runs as root on destination. Just to confirm, the user field in your rsync task has "root", right?

If so, is your destination folder somehow read-only even to root? What kind of a system is that? Can you post the result of "ls -al" on the destination folder?

 

[denningsrogue]

The target for the rsync is a freebsd server that does not permit root login. The rsync user on the freenas is a user with sudo privileges that logs into the freebsd target by ssh with a key. I don't believe this is a user/permissions issue because there is no problem with writes -- only deletions. If I uncheck the delete box, the task completes without an error. If the delete box is checked I get the "IO error encountered -- skipping file deletion" message.

 

[saurav]

On FreeBSD, there are also file flags and sticky bits.

https://www.freebsd.org/doc/handbook/permissions.html

Without getting more information on what is in the destination, it's impossible to say what's happening. You may try to set up an rsync task to a new directory with new files owned by the rsync user, and change the perms/flags one at a time to match the target you are having problems with, to find out the root cause.

As an aside, if the freebsd server is under your control, you can change the root login thing in your sshd config. Having a well managed/restricted SSH login as root is more secure than (password-less?) sudo. You can even restrict it to non-interactive tasks. Sudo isn't even used by rsync. Not saying that this is causing your issue, though it does fix a lot of issues with rsync permissions in general.