[Samba] Losing Permissions of Files

[Tanveer Virani]

Thanks. I've made the changes. Just waiting for a maintenance window to
restart the SAMBA service.

Tanveer


On Wed, Jun 12, 2013 at 6:39 AM, Jonathan Buzzard <jonathan at buzzard.me.uk>wrote:

> On Tue, 2013-06-11 at 20:22 -0600, Tanveer Virani wrote:
> > Hi Marc,
> >
> > Here is the information that you requested. When I say that "all
> > permissions on a file are lost", this is at the windows level. In Windows
> > Explorer, we go to open the file in the default program, we get an
> "Access
> > denied. Contact your administrator." error. When I right click on the
> file
> > and goto Properties -> Security, I get a "You do not have permission to
> > view or edit this object's permission settings." This usually happens
> after
> > someone has edited the file. It is not one individual or group that has
> > this issue. It could be anyone within the organization. These files are
> > mostly Microsoft Office files (xls, ppt, and doc).
>
> Hum, seen this been there.
>
> Basically Office goes through a complicated dance when you save a file.
> First it saves the file with a random name. Then it attempts to
> replicate the permissions from the old file onto the new file. Then it
> renames the original file to something random, before renaming the new
> file to have the original name. Finally it deletes the old file.
>
> The step that is "going" wrong is the attempt to replicate the
> permissions of the old file onto the new file. Roughly what is happening
> is the person saving the file does not have permissions to do anything
> with the file. The original owner of the file however does. For users
> sharing documents on a group share it makes the whole thing pointless.
>
> I came across this using Samba 3.5.x with a GPFS file system using NFSv4
> ACL's to store permissions. Though I replicated it with Posix ACL's on
> an ext3 file system for good measure. It only occurs with Office 2007
> and later. It was not picked up in initial testing because at the time
> we where still on Office 2003. Then an upgrade to Office 2010 was rolled
> out and the problems started.
>
> The solution required the correct storage of the DOS attributes, the
> appropriate configuration lines are
>
> # store DOS attributes in extended attributes
>         ea support = yes
>         store dos attributes = yes
>         map readonly = no
>         map archive = no
>         map system = no
>         map hidden = no
>
> You need to make sure that your file system is mounted with extended
> attributes as well. By default Samba attempts to map these attributes
> onto the permissions and this confuses the hell out of Office's
> permission replication stage. By storing this in the extended attributes
> it all starts working (note with GPFS if you use the vfs_gpfs module
> they actually get stored in the file system proper). It also has the
> added bonus that things like Thumbs.db files get the hidden bit set and
> don't show up in Windows Explorer.
>
>
> JAB.
>
> --
> Jonathan A. Buzzard                 Email: jonathan (at) buzzard.me.uk
> Fife, United Kingdom.
>
>