Word Errors

[Derrick Seymour]

I have had two constant errors for quite some time now.

First a little back ground.

I have a xServe G4 with OSX Server 10.3.4 providing authentication and home
directories for my users. A xServe RAID is what I am using for my storage
on the server. All clients have v.X Office on the computers, and all
computers are running OSX 10.3.4.


Here is my first error:

You cannot save while the file is in use by another process. Try saving the
file with a new name. (AutoRecovery save of Document1)

After clicking ok this other message appears:

Saving AutoRecovery file is postponed for Document1.

Obviously I have found this to be an Autorecovery issue, if I turn off
autorecovery, the problem goes away, not a great solution, but a quick fix
for now, but I am looking to turn this back on for all my users. Problem
definitely server based for I have tried reinstalling everything but the
kitchen sink on my clients.


Here is the second error I am receiving:

Word cannot save this file because it is already open elsewhere.

I have found no workarounds for this, let alone any information that could
explain how to fix it.

Any help would be greatly appreciated.




----------------------------------------------------------------------------

Derrick Seymour
Administrative Services
Northeastern Regional Information Center
Capital Region BOCES

----------------------------------------------------------------------------

 

[Mark Tovey]

"Word cannot save this file because it is already open elsewhere"

Here is the second error I am receiving:

Word cannot save this file because it is already open elsewhere.

I have found no workarounds for this, let alone any information that could
explain how to fix it.

Any help would be greatly appreciated.

I'm experiencing the same issue with OS X Server 10.3.3.

A few notes, which may or may not get us closer to a solution:

- the error occurs only when you have a home directory on a networked
drive
- the error occurs only when you are logged into a non-administrative
account

Two equally unpalatable workarounds suggest themselves:

- create local accounts for users who want to use Word.
- give all users who need to use Word administrative priviledges.

For one reason or other, Office generally does not deal well with
users who have home directories on a server. Excel, for instance,
experienced problems with this prior to the 2004 release (the problems
were macro-related. There's a Microsoft KB entry on this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;322237.
You'll notice that the two suggested solutions in this document
suggested by Microsoft are similarly impractical:

To resolve this issue, use either of the following methods:

• Move the Users folder back to the hard disk partition that contains Mac OS X.
-or-

• Reformat your hard disk to have a single partition.

Unfortunately, upgrading to Word 2004 does not fix the "you cannot
save this file" problem.

Neither, as it turns out does installing the Office for 2004 for Mac
Service Pack 1.

(I've also upgraded my client machines to 10.3.5, which is supposed to
improve access to home directories, also without effect.)

In fact, it may not even be a purely Mac problem. I'm wondering if
the roots of this go back
further.

Consider, for instance, in the Microsoft KB:

Description of how Word creates temporary files
http://support.microsoft.com/default.aspx?scid=kb;EN-US;211632

We learn some interesting things, especially that the location of
temporary files is hardcoded -- quite possibly also the case on the
Mac. I'm wondering whether this partly explains the fact that
Administrative users do not have these save issues (ie. they may have
permissions for directories on the server or on the local drive that
non-Administrative users do not have, which somehow ameliorates the
problem)

There are two Microsoft KB entries that mention this error on a
Windows version of Word. I'm trolling Windows docs for clues because
there's probably still a certain amount of common code base, and also
because I'm scraping the bottom of the barrel.

http://support.microsoft.com/default.aspx?scid=kb;en-us;832874

If you open a document in Microsoft Word 2002 that was saved to DocsOpen (a
document management program), you may receive the following error message when you try to > save your changes to the document: Word cannot save this file because it is already
open elsewhere.
http://support.microsoft.com/default.aspx?scid=kb;en-us;832287

This problem may occur if you have a mapped drive to the same location that your
VBA macro is trying to save changes to the document.

Also related to the DocsOpen program, only as accessed through a
macro.

I have a feeling that we're dealing with some legacy code in the
ancient heart of Word that still doesn't deal gracefully with
networked drives. Temporary files may also be a place to look.

My next move is going to be to update to Server 10.3.5 and see if that
addresses the problem.

Any other thoughts, however small, on this problem would be terrific.

Mark

--

Mark Tovey
System Administrator
Cognitive Development Lab
Carleton University

 

[John McGhie]

Mark:

If you know what you are doing with SymLinks, you can alias the temporary
file locations the user needs to the system Temp folder on their local
machine, to which they can be given full access.

If you can work out how to do this, that would seem to be a solution worth
exploring. I am afraid I am not a Unix person, so I don't know how to do
this. But Corentin is, and he should be a long in a moment

Cheers

"Word cannot save this file because it is already open elsewhere"






I'm experiencing the same issue with OS X Server 10.3.3.

A few notes, which may or may not get us closer to a solution:

- the error occurs only when you have a home directory on a networked
drive
- the error occurs only when you are logged into a non-administrative
account

Two equally unpalatable workarounds suggest themselves:

- create local accounts for users who want to use Word.
- give all users who need to use Word administrative priviledges.

For one reason or other, Office generally does not deal well with
users who have home directories on a server. Excel, for instance,
experienced problems with this prior to the 2004 release (the problems
were macro-related. There's a Microsoft KB entry on this:
http://support.microsoft.com/default.aspx?scid=kb;en-us;322237.
You'll notice that the two suggested solutions in this document
suggested by Microsoft are similarly impractical:





Unfortunately, upgrading to Word 2004 does not fix the "you cannot
save this file" problem.

Neither, as it turns out does installing the Office for 2004 for Mac
Service Pack 1.

(I've also upgraded my client machines to 10.3.5, which is supposed to
improve access to home directories, also without effect.)

In fact, it may not even be a purely Mac problem. I'm wondering if
the roots of this go back
further.

Consider, for instance, in the Microsoft KB:

Description of how Word creates temporary files
http://support.microsoft.com/default.aspx?scid=kb;EN-US;211632

We learn some interesting things, especially that the location of
temporary files is hardcoded -- quite possibly also the case on the
Mac. I'm wondering whether this partly explains the fact that
Administrative users do not have these save issues (ie. they may have
permissions for directories on the server or on the local drive that
non-Administrative users do not have, which somehow ameliorates the
problem)

There are two Microsoft KB entries that mention this error on a
Windows version of Word. I'm trolling Windows docs for clues because
there's probably still a certain amount of common code base, and also
because I'm scraping the bottom of the barrel.

http://support.microsoft.com/default.aspx?scid=kb;en-us;832874


Also related to the DocsOpen program, only as accessed through a
macro.

I have a feeling that we're dealing with some legacy code in the
ancient heart of Word that still doesn't deal gracefully with
networked drives. Temporary files may also be a place to look.

My next move is going to be to update to Server 10.3.5 and see if that
addresses the problem.

Any other thoughts, however small, on this problem would be terrific.

Mark

--

Mark Tovey
System Administrator
Cognitive Development Lab
Carleton University

--

Please reply to the newsgroup to maintain the thread. Please do not email
me unless I ask you to.

John McGhie <[email protected]>
Consultant Technical Writer
Sydney, Australia +61 4 1209 1410

 

[Beth Rosengard]

Mark:

If you know what you are doing with SymLinks, you can alias the temporary
file locations the user needs to the system Temp folder on their local
machine, to which they can be given full access.

If you can work out how to do this, that would seem to be a solution worth
exploring. I am afraid I am not a Unix person, so I don't know how to do
this. But Corentin is, and he should be a long in a moment

Cheers

 

[Corentin Cras-Méneur]

Mark:

If you know what you are doing with SymLinks, you can alias the temporary
file locations the user needs to the system Temp folder on their local
machine, to which they can be given full access.

It's worth a try, but for some reason, symlink don't always to the trick with
Office. Office X had the nasty habbit of using absolute path (and wrong ones)
instead of using relative ones and it completely messed up the Carbon
Registration Database for people with relocated User accounts (including
networked ones). Anyway, I can always help you with symlinks if you don;t
know how to create them. There are also several GUI apps around that can do
it for you npwadays.
(If you are using Office X, I have a trick for that for Macros, equation
editor..... - let me know).

Now when it comes to saving files, last I hear it was a MacOS X issue that
required to be perfectly up to date on all fronts (Server and Client).
Since I don't have a MacOS X server to "play" with, I never tested that
myself :-\

Another thing you could consider is copying the .plist and pref files
properly created in an admin account adn using them in a non-admin account.
If you're lucky, Office will be happy with them and it will stop bothering
you.

If you can work out how to do this, that would seem to be a solution worth
exploring. I am afraid I am not a Unix person, so I don't know how to do
this. But Corentin is, and he should be a long in a moment

Since I've been away for a while, I have a zillion posts I'd still like to go
through... As you can see it took me a bit longer to get to this one ;-))

Corentin

 

[Mark Tovey]

Hi Corentin,

Thanks very much for your thoughts on this. I updated the server to
10.3.5, and updated all the clients to the latest version of
everything. Everything is now up to date on both server and client.
No dice.

I need to correct one of my previous observations. Logging in with an
account with admin privileges does not actually correct the problem.
I must have accidentally gotten lucky the first time I tried logging
in through an admin account. So it sounds like it has less to do with
priviledges and more to do with the fact that the file (and the user
directory, particularly) is on a server volume.

To amplify this observation, consider the other phenomena which
disappear when logged into a local account:

1) Frequently when I launch Word, I get: "The custom dictionary
"Custom Dictionary" is not available."

2) It also has trouble saving the Normal file when quitting. The
error message:
"Changes have been made that affect the global template, "Normal". Do
you want to save those changes?"

3) Another user reported the autorecovery issues mentioned earlier:
"You cannot save while the file is in youe by another process. Try
saving the file with a new name. (AutoRecovery save of _______)" It
will then follow up with: "Saving the Auto Recovery file is post-poned
for _______) (I set the Autorecovery time to greater than 10 minutes
with the same result.)

Also, if I try to set the AutoRecover files directory to a server
volume, it tells me baldly: "The folder for this item cannot be on an
ejectable disk or network share. Please choose a folder on the hard
disk."

(It seems to allow the user to write to Temporary Files on the local
drive, which is what I ended up pointing this to). If you have more
specific ideas on where and how I could put in symbolic links, I'd
very gladly entertain them.

Thanks again,

Mark

 

[Corentin Cras-Méneur]

Hi Corentin,

Hi Mark,

Thanks very much for your thoughts on this. I updated the server to
10.3.5, and updated all the clients to the latest version of
everything. Everything is now up to date on both server and client.
No dice.

Argggggghhhh :-<

I need to correct one of my previous observations. Logging in with an
account with admin privileges does not actually correct the problem.

Even worse..

I must have accidentally gotten lucky the first time I tried logging
in through an admin account. So it sounds like it has less to do with
priviledges and more to do with the fact that the file (and the user
directory, particularly) is on a server volume.

Symlinks might indeed fool the system into considering the volume local
then - unless it's an issue with the network protocol (which I fear).
Did you try mounting the drive through smb instead of AppleTalk over IP
??

[...]

Also, if I try to set the AutoRecover files directory to a server
volume, it tells me baldly: "The folder for this item cannot be on an
ejectable disk or network share. Please choose a folder on the hard
disk."

Yeah, that's usually because of open temp files.

(It seems to allow the user to write to Temporary Files on the local
drive, which is what I ended up pointing this to). If you have more
specific ideas on where and how I could put in symbolic links, I'd
very gladly entertain them.

That's not easy...
If I quite remember, you have Office 2004 and the users accounts are on
a network volume ?? I'm not too familiar with the way it works (again, I
don't have MacOS X server to play with). Do all user account for one Mac
automatically mount in /Network or only the current user account ??

I guess Office itself is located in /Applications.

I was thinking in this case to create a symlink in /Users for each
networked user account and maybe even modifying the NetInfo Database to
point to /Users instead of /Network/Users.

That would definitively require a test machine (and maybe account) you
could afford to mess up to test this.

Nevertheless, I'm not even sure it could help. I suspect the problem
lies with the network protocol. In this case, and before messing around
with the user account or symlinking anything I would definitively try to
mount the current user account through smb and save through that. Since
it is a different network protocol, you could be able to save through
it. Is smb active on the server ??

Corentin

 

[Corentin Cras-Méneur]

Hi Mark,

I read an interesting article today:
http://www.thinksecret.com/news/0410briefly3.html

The article mentions that 10.3.6 should see improvements in many areas
including AFP... Hopefully that will correct your issue ;-\


Corentin

 

[Derrick Seymour]

Mark, Corentin,

I have found somewhat of a fix for this issue. Creating a temp folder on
all my clients then pointing Microsoft AutoRecovery files to save there.
Quick and easy, done with a script. It is sort of a work around but users
are able to still have autorecovery with no errors popping up. I believe I
read this suggestion on one of your posts.

_____________

Another error which I think is related that I receive still:

Word cannot save this file because it is already open elsewhere.

I click ok, this pops up:

An item named _______ already exists in this location. DO you want to
replace it with the one you are saving?

Then I click replace:

Word cannot save this file because it is already open elsewhere.

I click ok and it saves.

Quite bizarre. Not to sure why this is happening, currently looking for a
fix, I will post it if I find one.

______________

I hope at least some of this helped, thank you for your help


----------------------------------------------------------------------------

Derrick Seymour
Administrative Services
Northeastern Regional Information Center
Capital Region BOCES

 

[Corentin Cras-Méneur]

Mark, Corentin,

I have found somewhat of a fix for this issue. Creating a temp folder on
all my clients then pointing Microsoft AutoRecovery files to save there.
Quick and easy, done with a script. It is sort of a work around but users
are able to still have autorecovery with no errors popping up. I believe I
read this suggestion on one of your posts.

VERY nice indeed!! Thanks a lot for posting this wrkaround in the
newsgroup.

Corentin

 

[Mark Tovey]

Derrick, Corentin,

Thanks very much, Derrick, for posting the AutoRecovery workaround.
Derrick, you suggested that this could be done easily with a script.
Would you be willing to provide a few more details on what you did?

Thanks also Corintin, for the 10.3.6 heads up. I updated both client
and server to 10.3.6. (The behaviour, alas, persists).

I have one new thing to report on the "Word cannot save this file
because it is already open elsewhere" front.

When I create a *brand new account* (admin or non-admin), the "Word
cannot save this file because it is already open elsewhere" error
seems to disappear. This led me to wonder whether there were problems
with the Preferences in the existing accounts. I took one of the
non-admin accounts where I was experiencing the problem and deleted
all the Office or Word related plists in that account's
Library/Preferences/Microsoft folder, which didn't seem to do the
trick. Now I'm trying to think of other preferences I could try
deleting, or other ways in which an existing account might differ from
a new user account in ways which might affect the issue.

Mark

 

[mr.blair]

Has anyone found a reliable way to fix this issue yet? I've just
started having the "Word cannot save this file because it is already
open elsewhere" problem this week and have been trolling the d-boards
on apple, here and everywhere else I can think of - elsewhere its word
2000 with a macro issue, but on apple and here its at least the same
issue you-all seem to be having -- running multiple XServes w/10.3.5
Server and 300+ eMac/iMacs w/10.3.5 client - three user-groups, all
experiencing the saving issue.

Aaaarg is about all I can think to say.
Thanks
Blair C
Churchill School - NYC

 

[mr.blair]

In what seems like a fix, last night I worked on my servers, changing
my groups' "group folder"s in Workgoup Manager, making sure that the
group folder I assigned to them had r/w permissions for the admin user,
each 'group', and 'everyone' and today, it seems things are now working
fine for each user-group.
Huge relief there, and if anyone else runs into this problem, this
really seems to be the way to fix it.

 

[Daiya Mitchell]

Thanks very much for sharing, most of the regular visitors here don't have
that much experience with servers, so anything you add to the collective
archive in Google Groups (even if it's just a problem report) might be very
helpful to someone else.

Hope the fix persists.