Saving to NFS shares reverts permissions to umask

[christopher_mcca]

Version: 2008
Operating System: Mac OS X 10.5 (Leopard)
Processor: Intel

My setup:

- Intel Macs running Leopard 10.5.4 in a corporate environment
- Office 2008 12.1.1
- Macs authenticate users against NIS
- Many work directories, including home directories, are mounted over NFS using the automounter (Sun autofs in Leopard) working from NIS maps. NFS shares are on NetApp filers.

The problem: when opening and saving Office files stored on these NFS network shares, existing file permissions are lost, and replaced using the default umask (022), as if, instead of opening and saving the original file, a new file has been created.

Reproduction steps:

- Open an Office file (tested with .doc and .xls, as we are still on Office 2003 on the Windows side here).

- Observe that, if you look at the permissions prior to opening it, everyone has full permissions (Unix mode is 777). It does not appear to be relevant whether the user is the owner of the file or not.

- Make a change, and save the file.

- Recheck the file's permissions: observe that they have reverted to follow the default umask (Unix mode 755, the default for newly-created files). Everyone besides the user who saved the file now has read-only access where before they had read-write.

This is obviously a pain: while Windows Office 2003 users can open and save files with no problem, and maintain read-write permissions for everyone while doing so, as soon as a Mac user opens and saves the file, everyone else gets locked out into read-only access. The Mac user then has to remember to manually chmod the file back to read-write for everyone else.

Anyone else seen this problem, or have any recommendations?

 

[William Smith [MVP]]

The problem: when opening and saving Office files stored on these NFS
network shares, existing file permissions are lost, and replaced
using the default umask (022), as if, instead of opening and saving
the original file, a new file has been created.

Are you saying that his *only* happens with Office files? Have you
tested with other application files?

Dealing with umask over a network connection can be deceiving. The umask
on the server's folder isn't necessarily the umask of the sharepoint.
While I've never dealt with NFS I have had to deal with it for SMB. That
required some tweaking of the smb.conf file and was really tricky.

Ultimately, this should be handled by the server since I doubt Office
applications know anything about file permissions or umasks. Maybe
someone can chime in on the Save process. Is the original file *saved
over* or is it *replaced* with the temp file?

--

bill

Entourage Help Page <http://entourage.mvps.org/>
Entourage Help Blog <http://blog.entourage.mvps.org/>
YouTalk <http://nine.pairlist.net/mailman/listinfo/youtalk>
Twitter: follow <http://twitter.com/meck>

 

[christopher_mcca]

Hi Bill, thanks for your reply.

Are you saying that his *only* happens with Office files? Have you
tested with other application files?

I can confirm that this does not necessarily occur with other applications. For example, I tested with a .rtf file created and saved in TextEdit. I had another user create the file and save it to an NFS share (and set full read-write for everyone 777 permissions). I opened the file in TextEdit, made a change, and saved it. Checked permissions afterward: although *ownership* of the file changed from the other user to me, the mode of 777 was preserved, which would be the desired behavior for Office.

Ultimately, this should be handled by the server since I doubt Office
applications know anything about file permissions or umasks. Maybe
someone can chime in on the Save process. Is the original file *saved
over* or is it *replaced* with the temp file?

Those are the lines along which I was thinking: Office apps are not changing permissions per se on existing files (which, as you say, I don't think they would know anything about or be able to affect), but rather are creating new files and replacing existing files with these new files. I'd also love it if someone with knowledge of the Save process had any input to provide.

Thanks again,

Chris