[Solved] File permissions CICFS Windows / rsync conflict

[tr0910]

I have been setting up an rsync of windows workstations from unraid and it works wonderfully, except that after the files arrive on unraid, windows cannot seem them.  The world execute bit is set.  Chmod 700 fixes it, but the next rsync run sets them all back again.  Since I will have rsync runs happening very frequently, I would like it to leave the file permissions alone.  Tom references it here: http://lime-technology.com/forum/index.php?topic=4776.msg43822#msg43822

 

-rwx------ 1 root root 13213880172 Aug 22  2010 file1*

-rwx-----x 1 root root 13213880172 Aug 22  2010 file2*

            ^-that is the world execute bit

 

Is there a way to fix this so rsync runs dont create these file permission problems?

 

Is this fixed in V5 or should I install NFS on Windows?

 

[Spectrum]

Overide the perms with the mount command.

mount -t cifs //server/share /mnt/tmp -o file_mode=0644

 

0644 mounts it as rw for root and read only for everyone else.  That's the perms most of my files have in my array.

[BRiT]

Yes, read and understand the post immediately before the one you linked to.

 

It depends on how you configured SAMBA to map additional non-unix attributes, like the WinOS HIDDEN flag.

 

Look into the SAMBA options of "map hidden", "map archive", and "map system" within the smb.conf man pages.

 

 

In the current version of samba, both "map hidden" and "map system" default to "Yes".

You can easily change that by adding the following two lines to the global section of your smb-extra.conf

   map hidden = No
   map system = No

 

If smb-extra.conf doesn't exist in the config folder of your flash disk, create it!

The easiest is to just telnet to your server and type in the following two lines:

echo 'map hidden = No' >> /boot/config/smb-extra.conf
echo 'map system = No' >> /boot/config/smb-extra.conf

 

And then restart your array.

 

[Spectrum]

The downside to removing samba's mapping scheme is you lose the ability to have files marked as hidden/system on your array.  This means if you copy a file across to the array that is a hidden/system file then copy it back off, it is no longer a hidden/system file.  End of the world?  Not really, but disabling the feature is using a shotgun instead of a scalpel.

 

The only time this problem crops up is when mounting through cifs on the unRAID box.  If you are copying files from one place in the array to another, the perms are preserved.  If you are using NFS the perms are preserved.  The CIFS driver mounts everything as 0777 which is a tad ridiculous IMO, but that's what it does.  Solving the problem is using the

file_mode

option to override this behavior.  Treating the symptom is blowing out Samba's ability to maintain hidden/system files for your Windows boxen.

[tr0910]

The downside to removing samba's mapping scheme is you lose the ability to have files marked as hidden/system on your array.  This means if you copy a file across to the array that is a hidden/system file then copy it back off, it is no longer a hidden/system file.  End of the world?  Not really, but disabling the feature is using a shotgun instead of a scalpel.

 

The map hidden proposed by Brit seems to work, but as I was about to try yours, I touched one of my server drives, to check temp, and a bit of static electricity jumped from my finger to the drive, causing a server reboot.  Thankfully this was unraid2 in the process of being built, with only 2 drives in it, no parity yet, and a third drive just starting to format after a preclear.  Now we have reiserfs errors on reboot, but otherwise everything seems to be working normal.  Should I worry?  log attached.

 

I would just run a reiserfsck except disk3 was just added and was just in process of formatting.  Is this still the right way to go?

syslog.txt

[Joe L.]

The downside to removing samba's mapping scheme is you lose the ability to have files marked as hidden/system on your array.  This means if you copy a file across to the array that is a hidden/system file then copy it back off, it is no longer a hidden/system file.  End of the world?  Not really, but disabling the feature is using a shotgun instead of a scalpel.

 

The map hidden proposed by Brit seems to work, but as I was about to try yours, I touched one of my server drives, to check temp, and a bit of static electricity jumped from my finger to the drive, causing a server reboot.  Thankfully this was unraid2 in the process of being built, with only 2 drives in it, no parity yet, and a third drive just starting to format after a preclear.  Now we have reiserfs errors on reboot, but otherwise everything seems to be working normal.  Should I worry?  log attached.

 

I would just run a reiserfsck except disk3 was just added and was just in process of formatting.  Is this still the right way to go?

It thinks there is a corrupt file system on disk3. 

[tr0910]

The map hidden proposed by Brit seems to work, but as I was about to try yours, I touched one of my server drives, to check temp, and a bit of static electricity jumped from my finger to the drive, causing a server reboot.  Thankfully this was unraid2 in the process of being built, with only 2 drives in it, no parity yet, and a third drive just starting to format after a preclear.  Now we have reiserfs errors on reboot, but otherwise everything seems to be working normal.  Should I worry?  log attached.

 

I would just run a reiserfsck except disk3 was just added and was just in process of formatting.  Is this still the right way to go?

It thinks there is a corrupt file system on disk3.   

 

reiserfsck --fix-fixable seems to have made it ok.

 

I was leery of running this since the drive was being formatted when it rebooted.

 

[Spectrum]

Re-reading my response above it sounds a bit aggressive towards Brit's solution.  That was not my intent in the least and apologies Brit if you read it and interpreted it that way.  It's way too easy to mis-convey things when communicating via text

 

Both are valid methods for solving your problem, however, there are repercussions if you remove Samba's ability to map hidden/system files (for Windows boxes) on your array.  If you are fine with that than it is a good solution.  At the end of the day, we just want things to work!

 

If you want to avoid this problem all together, the easiest way would be to script your Windows machines to back up to Tower1 (rather than having Tower1 run the backup for each machine) and then use NFS mounts or rsync as a daemon process to backup from Tower1 to Tower2.  All the perms would be maintained that way.

 

There is cwRsync for Windows, or you could use xcopy or robocopy to script the backup from the Windows boxes to the Tower1 if you want to investigate that as an option.

 

Glad Joe got you all fixed up on the reboot problem.

[BRiT]

No offense or aggressiveness read into it, so nothing to worry about. 

 

I want to make sure I follow your means, does your mounting of the share using the file_mode parameter still allow for windows to map attributes to the share? I guess I'm not entirely certain if your method overrides the original share or if you're providing an alternative view to the same files where the mapping / reading of the files would then simply not export as being hidden/system?

 

I agree that for critical files one should be careful with maintaining the appropriate hidden/system/archived attributes. I would use rsync on personal files/folders which should not be concerned with system/hidden attributes, while I suppose that if possible it's best to allow a dedicated native OS backup system to do it's part on the critical OS files which are very particular on those additional attributes.

[Spectrum]

No offense or aggressiveness read into it, so nothing to worry about. 

 

I want to make sure I follow your means, does your mounting of the share using the file_mode parameter still allow for windows to map attributes to the share? I guess I'm not entirely certain if your method overrides the original share or if you're providing an alternative view to the same files where the mapping / reading of the files would then simply not export as being hidden/system?

 

Yes, forcing the file_mode parameter allows for the files remain mapped as hidden/system on the original location; however, once you copy that file from the CIFS mount to another location, the copies files are going to have whatever perms you set using the file_mode parm.  Mounting via CIFS and trying to maintain the Windows attributes is just not possible.  You get either the 0777 that is default, or whatever you override it with.

 

Example (Samba mapping HSA is on):

Machine win1 (Windows OS) has a share foo and foo has the following files

A  SHR  I    file1
A   H   I    file2
A  S    I    file3
A       I    file4

A=Archive,  S=System,  H=Hidden,  I=Not content indexed

 

If \\win1\foo is mounted in an unRAID box using

mount -t cifs //win1/foo /mnt/tmp

doing an

ls -l

on /mnt/tmp would produce

-rwxrwxrwx file1
-rwxrwxrwx file2
-rwxrwxrwx file3
-rwxrwxrwx file4

So if you copy any of those file to your array (the permissions would copy as listed above 0777), then the effective windows attributes would be

A  SH        file1
A  SH        file2
A  SH        file3
A  SH        file4

If you instead mounted the share from an unRAID box with

mount -t cifs //win1/foo /mnt/tmp -o file_mode=0644

doing an

ls -l

on /mnt/tmp would produce

-rw-r--r-- file1
-rw-r--r-- file2
-rw-r--r-- file3
-rw-r--r-- file4

So if you copy any of those file to your array (the permissions would copy as listed above 0644), then the effective windows attributes would be

             file1
             file2
             file3
             file4

 

So now from the above, if you copy those files to your array with the 777 perms then tried to view from a windows box, everything would be hidden and using the 644 perms, they would not.  That is the case regardless of the original attributes on the windows box.

 

Now as an example for tr0910's benefit:

If you mount \\tower1\backup on win1 then copy the files across, they would maintain their windows attributes which would be mapped into *nix file perms.

-r-x--x--x file1
-rw------x file2
-rw---x--- file3
-rw-r----- file4

 

You could then replicate from tower1 to tower2 using an NFS mount or using rsync as a daemon and you could preserve the permissions.  Then you maintain the windows attribs through the whole chain and don't have to worry about things getting buggered due to CIFS mounts with the unRAID boxes.

 

Now it's clear as mud right