For my rsync driven backup solution to work I need to have all files world/other readable.

 

For version 4.0 I had changed the smb.conf to update the create mask and directory masks to do this for me.  In that case I set

 

create mask = 0744

directory mask = 0755

 

Now it appears that with 4.2+ this is automagically created, probably something to do with the user shares, who knows, but it resides in the /etc/samba/smb.shares file.  I can see that the masks are set to 0711 which does not allow world/other reading.  So now my backup solution is broken.

 

I could copy and edit the smb.shares file, and move it to /etc/samba in my go script, but what else with that break?  Would I need to update that everytime I change a mount?

 

Any reason why the defaults cant be 0744 and 0755 for create and directory?

 

thanks,

David

I'm not sure why you need this.  Please post a description of your backup solution, your rsyncd.conf file on the unRAID server, and the rsync command line you're using on the client (and btw, is the client a windows PC?).

 

It might be helpful to know this - the unRAID s/w is first & foremost a Samba server - that is, we want to interoperate with Windows networking as easily as possible.  (At least this is the current focus.)

 

So on the server side, all user authentication is done via Samba, or more specifically, Samba control via 'valid users' and 'invalid users' parameters in the smb.conf file.

 

To simplify things, on the server side, we try to keep every file system object (file & directory) owned by 'root', and every Samba operation on the server side takes place as user 'root' regardless of what user actually connects to the server.  So there's really no concept of "other" and "world" users.  Does this make sense?

I use BackupPC, a unix backup solution.  The backup servers is at my brother's house, giving me off site backups.

 

BackupPC use rsync to access UnRaid and I do not allow it to come in as root.  Instead I use a secrets file and it comes in as backuppc.  This is what requires other/world access to the files.

 

Hope this helps,

David

More details:

 

My rsyncd.conf file setups up each directory that I want to have backed up, and allows my backuppc user.

 

/boot/config/rsyncd.conf

gid = nobody

uid = nobody

log file = /var/log/rsyncd.log

 

[music]

        path = /mnt/disk4/My Music

        comment = music collection

        read only = yes

        list = yes

        auth users = backuppc

        secrets file = /etc/rsyncd.secrets

 

My secrets file provides the password used by BackupPC to get access.

/etc/rsyncd.secrets

backuppc:password

 

In my smb.shares file I change the masks to allow other read access.

/boot/config/smb.shares

[disk4]

        path = /mnt/disk4

        read only = No

        force user = root

        map archive = Yes

        map system = Yes

        map hidden = Yes

        create mask = 0744

        directory mask = 0755

 

Then my go script sets it all up for reboots.

/boot/config/go

cp /boot/config/secrets /etc/rsyncd.secrets

chmod 400 /etc/rsyncd.secrets

rsync --daemon --config=/boot/config/rsyncd.conf

/etc/rc.d/rc.samba stop

cp /boot/config/smb.shares /etc/samba/smb.shares

/etc/rc.d/rc.samba start

 

Hopefully this makes sense.  I really don't want to allow root access through rsync.  SSH does not exist so I can't tunnel through that.

 

This has been working for sometime now and I really like the idea of backup up my data.  It has saved my bacon a couple times already.

 

If you see a better way to do this I'm open for suggestions.

 

thanks,

dave

I think all you have to do is change these lines in rsyncd.conf:

 

gid = nobody

uid = nobody

 

to

 

gid = root

uid = root

 

And then you don't have to modify the smb.shares file at all.

 

If the files are still not being written with the correct permissions, you might try adding this line to the module section:

 

incoming chmod = 0700

I had thought about that, but was not sure what kind of security risks that might pose.  Of course I'm only allowing read access to the partitions so maybe it is a nit.

 

thanks,