Linux RSYNC Permissions Issues - FREENAS

[Exos]

Hello guys, it's been a while since i've asked for help on here, but after a bit of a bad week in general, I'm beginning to tear my hair out and am losing the will to live.

This may be one for HH, but I could do with a little bit of help please

After having two disks fail in a RAID array at the same time, and a limited backup mechanism in place for the amount of data i have, I'm now running a backup of some specific files and folders from a QNAP569 Pro NAS to a FREENAS VM sitting inside a network attached server

Here's the issue.

I've created the volume, datasets and CIF's shares on the FreeNAS server; I've set an RSYNC job up from the QNAP to connect and copy the data, it connects fine, creates all the folders at the backup location in the shares, but fails when trying to copy the actual files across (which is weird as it clearly has privileges to write). The RSYNC job itself actually runs to completion.

I can actually create folders, files etc manually with no issue in the target share using my domain account.

[I'll post the specific error message here soon, but it appears to be permissions based, as if the QNAP is trying to change them at the target location (CHOWN), but isn't being allowed to naturally as it doesn't have permission to change attributes]

You don't have permission to view the code content. Log in or register now.

So bit of config background.

- The QNAP is domain affiliated and access to it's shares are from the domain admin account/group for RW, and other accounts for RO.
- The FreeNAS server is also domain affiliated
- The owner on the shares on the QNAP is NAS\Admin
- The RSYNC job FROM the QNAP has been setup and tested to use both root/wheel and the domain admin accounts for access to the CIFs, with the same result
- The FreeNAS server has had similar where I've changed permissions/ownership to be the same, with the same result.

So, here's what I've tried so far:

- edited the rsync.conf file to set the UID/GID as root/wheel. No Change
- Used both domain accounts and unix native accounts for the RSYNC jobs. No Change
- Blown away all the datasets and shares, and used Unix based only. No Change
- Tried 'guest' access. No Change.
- changed the owner on the QNAP shares, from NAS\Admin, to be the specific domain account and also set it to be exactly the same on the FreeNAS server. No Change

Idea's on a postcard please.


Thanks

 

[Him Her]

CIFS config files would be useful but as a first stab, although the user/group names may match, the numeric UID/GID must match too.

 

[Exos]

CIFS config files would be useful but as a first stab, although the user/group names may match, the numeric UID/GUID must match too.

I've tried that though by editing the rsync.conf file and changing the UID/GID to be exactly the same as on the FreeNAS server, It's as if the credentials being set are completely being ignored by the QNAP and it's using whatever it pleases.

This is the config file from the source.

You don't have permission to view the code content. Log in or register now.

 

[Him Her]

In the first two lines of the config you set UID to root and GID to wheel but this doesn't set the connecting user UID/GID, it sets the owner attributes on the written files. This is probably the problem as the connecting user is rsync.

What I meant was the connecting user should exist as a CIFS user and the CIFS client should authenticate using those credentials. You should ensure there is no user with the same name on the client unless the UIDs match.

In the config file you should set the UID to rsync and the GID to a group that rsync is a member of. The target should match the source.

 

[Exos]

In the first two lines of the config you set UID to root and GID to wheel but this doesn't set the connecting user UID/GID, it sets the owner attributes on the written files. This is probably the problem as the connecting user is rsync.

What I meant was the connecting user should exist as a CIFS user and the CIFS client should authenticate using those credentials. You should ensure there is no user with the same name on the client unless the UIDs match.

In the config file you should set the UID to rsync and the GID to a group that rsync is a member of. The target should match the source.

So, I also changed the UID/GID to be that of the 'domain' account which has priviledges to the share. Would this not work?
I also changed the rsync account to the same, again, would that not also work given it's that account that has the privileges, or would i be better setting this to the root account (or the rsync account above) on the FreeNAS Server?

What concerns me, is that in the rsync screen when i setup the connection to the target, whether i put credentials in or not it tests as successful, which to me seems to indicate that doing that has no effect whatsoever.

 

[Him Her]

It's probably just testing the ability to connect then failing at the write stage. Whichever user connects should exist as a CIFS user on the target, the UID in the config on the target should be set to the same as the connecting user. The group should be set up similarly i.e. a CIFS group that the connecting user is a member of, set the config file GID on the target to CIFS group.

Share permissions are not the same as file permissions, just like Windows.

 

[Exos]

Isn't creating a folder a write action though, so why create the folder, but not the file?

My interpretation of the above is that the rsync job is trying to alter either the timestamp or owner on the target, but can't despite the fact the account has the necessary privileges, whether it be domain level, or unix type accounts. I've also ensured (with different accounts) users exist in both locations.

 

[Him Her]

What's the config file look like on the target?

 

[Exos]

Currently:

You don't have permission to view the code content. Log in or register now.

 

[Him Her]

I'm betting the created folders don't have permissions set as rsync (user) and wheel (group)?

 

[Exos]

I'm betting the created folders don't have permissions set as rsync (user) and wheel (group)?

Yep, they do

 

[Him Her]

How strange. What are the permission strings for the share and the created folders? Also, what's the mount command that rsync is using? Do the UIDs and GIDs match numerically on both source and target?

 

[Exos]

How strange. What are the permission strings for the share and the created folders? Also, what's the mount command that rsync is using? Do the UIDs and GIDs match numerically on both source and target?

RW on the FreeNAS box, Full Control on the accounts that are used for the CIFs, don't know the mount command as it's native to the NAS (kind of a point and go), UID/GID's match.

I'm doing a full factory restore on the FreeNAS server, just going to start again and see where that takes me.