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 <[email protected]>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. > > -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
