Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have a windows share on a windows2003 server (WINJOE) which I want to back up to a Linux machine (LINUXJOE) that is properly joined to the domain. My goal is to backup shared folders of WINJOE to LINUXJOE while keeping windows permissions/owners. After reading the relevant literature, I am under the impression that this is not possible...

Anyway, in an ideal world, I would like to mount a win share (as read-only), e.g. \\WINJOE\important_folder, on LINUXJOE and run rsync from there to the backup directory.

What I have so far:

\\WINJOE\important_folder -> shared folder to be backup up
LINUXJOE: /mnt/important -> mount point of \\WINJOE\important_folder on LINUXJOE
LINUXJOE: /backup/$DATE-important -> backup target directory

At the moment I am able to login using my windows domain account to LINUXJOE, and if I create files on LINUXJOE's filesystem, they show the owner as "somewinuser "domain users"", so user mapping from windows to linux works ok. When I mount \\WINJOE\important_folder using the following command:

linuxjoe# mount.cifs //WINJOE/important_folder /mnt/important \
-o ro,user=backitup,dom=TODOMAIN,cifsacl,nounix  --verbose

I get:

ls -latrh

linuxjoe# ls -latrh /mnt/important
total 518M
-r-xr-xr-x 0 root root         518M Sep 28 01:19 test.mkv
-rwxr-xr-x 0 root root            0 Oct 25 19:04 testlalala
-rwxr-xr-x 0 root root            0 Oct 25 19:05 testkoko
drwxrwxrwx 1 root domain users    0 Oct 25 19:05 .
drwxr-xr-x 5 root root         4.0K Oct 29 16:29 ..


getcifsacl

linuxjoe# getcifsacl /mnt/important/test.mkv
REVISION:0x1
CONTROL:0x8404
OWNER:BUILTIN\Administrators
GROUP:TODOMAIN\Domain Users
ACL:Everyone:ALLOWED/I/FULL
ACL:NT AUTHORITY\SYSTEM:ALLOWED/I/FULL
ACL:BUILTIN\Administrators:ALLOWED/I/FULL
ACL:TODOMAIN\lukeskywalker:ALLOWED/I/FULL

rsyncing:

linuxjoe# rsync -apvXAgo /mnt/important/koko.mkv  /root/test/

linuxjoe# ls -latrh  /root/test/
total 518M
-rwxrwxrwx 1 root domain users 518M Sep 28 01:19 test.mkv
drwx------ 8 root root         4.0K Oct 29 18:29 ..
drwxr-xr-x 2 root root         4.0K Oct 29 18:29 .

Is it in any way possible, to view the proper owner of files on windows shares, and keep that owner along with all windows security attributes when I rsync from a windows share to my linux backup box?

smb.conf

[global]
workgroup = TODOMAIN
realm=SOMEOFFICE.SOMEWHERE.GR
server string = %h server
wins support = no
security = ads
encrypt passwords = yes
obey pam restrictions = yes
template shell = /bin/bash
template homedir = /home/%D/%U
password server=winjoe.someoffice.somewhere.gr
domain master = no
local master = no
prefered master = no

idmap config * : backend = rid
idmap config * : range = 5000-3000000000
idmap config * : base_rid = 0

idmap config TODOMAIN : backend = rid
idmap config TODOMAIN : range = 5000-3000000000
idmap cache time = 900
algorithmic rid base = 5000
client schannel = no
disable spoolss=yes

winbind separator=+
winbind use default domain=yes
winbind nested groups=yes
winbind enum users=yes
winbind enum groups=yes
winbind cache time= 300
winbind refresh tickets = yes

inherit acls = Yes
map acl inherit = Yes
acl group control = yes
share|improve this question

2 Answers 2

up vote 1 down vote accepted

Unfortunately Linux ACLs and Windows ACLs are very different. When you access a Linux filesystem from Windows via Samba, Samba manages to map the simpler Linux ACLs to Windows ACLs without losing too much information. For this to work you already need many of the options you have in your smb.conf.

The other way around is much harder and probably even impossible, especially as a Linux mount has a different semantics than a Windows mapped share. And the mount happens with a kernel driver that doesn't implement the ACLs at all. The only way we have is to get the information with additional programs like getcifsacl.

So normal Linux tools like rsync don't know anything about the Windows ACLs and can't store them. If you need to restore those ACLs, you'll need to save them yourself with getcifsacl and restore with setcifsacl. As these commands only work on single files unfortunately and setcifsacl cannot work with the output of getcifsacl directly, you'll need a sofisticated set of scripts to backup/restore those ACLs. A quick search didn't show any existing solution.

One way around this would be to let Windows do the backup and use a Linux share as storage for backup files (not individual files).

share|improve this answer

How about creating big file in samba directory and mounting it as loop? This is how it could work, based on great article http://users.softlab.ntua.gr/~ttsiod/backup.html

dd if=/dev/zero of=/mnt/windows/BigFile bs=1M count=1 seek=150000

mount.cifs //WINJOE/important_folder /mnt/important \
-o lfs,user=backitup,dom=TODOMAIN,cifsacl,nounix  --verbose

By default, Samba mounting has a file size limitation of 2GB (or 4GB, not sure). This is why the "lfs" option is used in mounting, to allow for larger files.

mount -o loop /mnt/important/BigFile /mnt/backup

losetup /dev/loop0 /mnt/windows/BigFile

optionally, using encryption: losetup -e aes256

mkfs.ext4 /dev/loop0
mount /dev/loop0 /mnt/important/BigFile
cd /mnt/important/BigFile
rsync -avz --exclude /proc --exclude /sys root@server:/ ./            
share|improve this answer
    
The problem remains I am afraid, as the article you mentioned says: "The big one remained: the permissions/owners issue". In addition to this, the article is more than 6 years old and it addresses a different issue –  jijix Feb 14 at 14:06
    
Have you read the whole article? You're not right - permissions/owners issue is when you just backup to samba. When you create big file, format it as ext4 and mount it as loop, it will work. The article is quite old, but the concept is still valid. Btw. see "Now that solves many issues... The /mnt/backup folder will be used as rsync's destination, and since the actual filesystem inside BigFile can be any Linux supported fs (Ext3, ReiserFS, etc), UNIX permissions and owners will be kept just fine!" –  pevik Feb 15 at 9:16
    
The title of my question is a little misleading to be honest, same as in the article. The problem is actually the acls not the owner/permissions per se, and that is not solved yet. –  jijix Feb 17 at 14:49

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.