MacInTouch Reader Reports

Office 2004: Save to Server Bug

Nov. 7, 2009
Nov. 5, 2010
Nov. 6, 2010
Mar. 25, 2011
Mar. 26, 2011
Nov. 7, 2009

item.103960

MacInTouch Reader

I too am having this issue on both bound machines that use the Active Directory UID as well as unbound machines that I have personally changed the local user uid's to unigue #'s. I have the .temporaryitems folder at the root of all the shares. We are saving to a Windows 2003 server that is fully patched.

My department has worked one on one with Apple to resolve the issue and so far no luck. All we heard was I don't know and have you checked your ACL's

Nov. 5, 2010

item.124018

Colleen Thompson

Having just read the entire Save To Server Bug thread and not finding a definitive answer, I appeal to the excellent MacInTouch community.

A small office (2 iMacs running 10.5.8) shares Word 2004 and PDF files in this way: one iMac's drive is partitioned, with one partition set as a sharepoint in File Sharing. Both users are defined as having Read/Write access to the sharepoint, so they are not using the same ID when accessing it.

Problem: many files end up being Read Only for the client user. This was confirmed by checking Get Info for random files. I can temporarily fix things by repropagating RW to all enclosed files and folders in Get Info but am sure the problem will return.

Extensive googling has led me to make sure their local UIDs are different (one is 501, one is 502); and that the hard drive names are different from the sharepoint name. Also, the permissions on imbedded folders do not seem to affect the files inside (in case the problem was caused by creation of folders with incorrect permissions.)

I can try the Temp Items fix suggested on 2/27/2006, if anyone thinks that might help. I should also mention that we've been wrestling with this, on and off, for several years; we did once try Sharepoints instead of native file sharing (that was in 10.4), and an NAS (which died, and was rather unsatisfactory anyway.)

I could upgrade them to Office 2008 if it would help, but I have another client having different network problems with that, for which I'll post something in that Macintouch thread.

Thanks for any enlightenment!

Nov. 6, 2010

item.124138

Geoff Strickler

Colleen Thompson write:

Problem: many files end up being Read Only for the client user. This was confirmed by checking Get Info for random files. I can temporarily fix things by repropagating RW to all enclosed files and folders in Get Info but am sure the problem will return.

The issue is that Word/Excel (and most other programs) don't actually update a file when they save it, they delete the old one and save a new one. When they do that without adding code to copy the permissions from the old file, the new file can (and usually will) have different permissions.

Use ACLs (Access Control Lists) rather than the standard Unix type file permissions. They're much more flexible and permissions for new files can be inherited. Unfortunately, you have to assign them from a command prompt in terminal. Here's an example of creating ACLs that allow all users of a machine to share files in a directory (and it's subdirectories), even new and updated files:

' Give group "staff" (all Mac OS X users) read/write access to all new/updated files and directories in the specified path

sudo chmod -R +a "staff allow readattr,readextattr,readsecurity,list,search,read,execute,file_inherit,directory_inherit,writeextattr,writeattr,write,append,delete_child,add_file,add_subdirectory" /path-of-shared-directory

If you want to limit it to a select group of users, you'll need to create a new group that has those users and replace "staff" with the name of that group.

item.124144

Patrick Fergus

Colleen's issue isn't Word-specific. It has to do with OS X's "...default [settings]...[that create permissions so] groups and other users can read the files and traverse the folders, but only the owner can make changes" (Apple KBase article HT2202). Use Access Control Lists (ACLs) to provide access to the files. ACLs are evaluated (and permissions granted or denied) before the standard POSIX permissions.

First, log in as an administrator and create a group (I'd strongly suggest using a lowercase group name with only alphanumeric characters for simplicity):

http://docs.info.apple.com/article.html?path=Mac/10.5/en/11626.html

Add the users you wish to share files to this group.

Next open Terminal (Macintosh HD:Applications:Utilities:Terminal) and type the following (this should all be on a _single_ line _without_ the backslashes and _without_ spaces after the commas--it is broken up here for clarity), replacing "your_group_name_here" with the group name you chose above. However, do NOT press Return until you read the rest of the instructions:

sudo chmod -R +a "your_group_name_here allow\
list,add_file,search,delete,add_subdirectory,delete_child,\
readattr,writeattr,readextattr,writeextattr,readsecurity,\
file_inherit,directory_inherit"

Next add a space (press the space bar) after the above command.

Then drag the folder (or drive partition) you wish to share to the Terminal window. This should result in the path to your shared files being appended onto the command above--judging by your description of your setup it should be something like:

/Volumes/Second\ HD\ Partition/Shared\ Files

Your final command will resemble the following (I've removed some of the rights so this all fits on a single line--you _do_ want all the rights listed above):

sudo chmod -R +a "sharingusers allow list,add_file,search,delete" /Volumes/Second\ HD\ Partition/Shared\ Files

Finally, press Return and enter the administrator's password.

If you're uncomfortable with performing the above Terminal command on your live data, create additional temporary sharepoints in the Sharing Preference Pane and practice/test the procedure with those non-critical sharepoints to make sure it's setting privileges the way you expect. Also note "In order for the ACL permissions to be inherited, the item(s) must be created in the folder (which sets the inherited permissions on the new file), not moved there (which does not change the existing permissions)." (taken from the discussion here:)

http://discussions.info.apple.com/message.jspa?messageID=11209577

This may be a concern if the user of the "server" drags files and folders into the sharepoint rather than creating and working directly on the files there.

item.124157

John Baltutis

Colleen Thompson wrote:

"A small office (2 iMacs running 10.5.8) shares Word 2004 and PDF files in this way: one iMac's drive is partitioned, with one partition set as a sharepoint in File Sharing. Both users are defined as having Read/Write access to the sharepoint, so they are not using the same ID when accessing it."

See http://discussions.apple.com/thread.jspa?messageID=12528253

Mar. 25, 2011

item.132272

Colleen Thompson

Thanks to all who responded to my 11/5/2010 plea for help in the Save To Server Bug discussion here.

I did the creation of the .TemporaryItems folder in November, and it (or perhaps my re-propagation of permissions) solved things for a few months. But now it's back with a vengeance, so I will proceed with the suggested ACL solution detailed by Geoff Strickler and Patrick Fergus.

But first, a question. Patrick offers this caveat: "This may be a concern if the user of the "server" drags files and folders into the sharepoint rather than creating and working directly on the files there."

This *is* a problem, because many of the documents arrive via email, and I can't expect the main user (a lawyer who has much more important things on his mind) to remember to not drag folders into the sharepoint.

I wonder if Dropbox, perhaps its shared folder feature, would work around this? I know it keeps a local copy and so would have the same ACL issues, but maybe a Dropbox shared folder would evade this somehow? I use Dropbox a lot, but not for sharing, and I will look into it, but would appreciate any feedback.

item.132274

Colleen Thompson

One comment on Patrick Fergus' statement:

"Colleen's issue isn't Word-specific. It has to do with OS X's "...default [settings]...[that create permissions so] groups and other users can read the files and traverse the folders, but only the owner can make changes" (Apple KBase article HT2202). Use Access Control Lists (ACLs) to provide access to the files. ACLs are evaluated (and permissions granted or denied) before the standard POSIX permissions."

That does not explain why this only happens with Word and Excel; you can open the very same Word files with TextEdit and have no problem editing and saving them. So I still think this is somehow involved with the .TemporaryItems folder or some other Office-specific feature.

Mar. 26, 2011

item.132362

Monte Fruits

If this is the problem I think it is, it has nothing to do with permissions. There is a problem specific to Microsoft Word that (usually) only happens when you save your files on a server, but you use local accounts on your user machines. This is caused by the UID assigned to the local accounts. By default they start at 501 and increment as you add user accounts to the computer. So if you started with an admin account at 501, your next user account would be 502. Word identifies it's temporary files by the user's UID. If two (or more) users with the same user id have Word files open from the server, when one of them quits Word, all the temporary files with that UID are deleted. The other users with that UID are, well, screwed. Word can't find the temp files, so...

The only cure for this is to change the UIDs for all your users to a unique number (I think they can be anything from 501 to 65k). Or change to network accounts instead of local accounts. This is not a problem if you have network accounts because the server assigns unique UIDs to every user.

There should be a Microsoft support document on this. Also, there are two commands that can be issued in Terminal to change a UID, and change all their files.


MacInTouch Amazon link...

Talk to MacInTouch     Support  •  Find/Go