Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

10.4.x Finder bug with AFP mounted home directory during a copy

We have at least 500 macs connected to various xserve's all running the latest OS (10.4.x) Server and (10.4.x) Client. When a network user logins in and recieves a home directory mounted through AFP (Share is not using ACLs) we find that in several cases when they perform a copy of a file by holding down the option key from any afp mounted folder it will sometimes produce a message saying the original file exists and your only option is to press ok. Once you do this both the original file and the copy disappear. For anyone with this setup please try the following. I'm looking for others with the same issue. The steps listed below may have to be repeated anywhere from 1-100 times it's very random. Once the behaviour occurs it will happen more frequently during your login session.

1) Create a simple text file and save it to you afp network mounted desktop.
2) Select the file and hold down option to drag the file which will then create a copy.
3) Repeat several times until a message is reported. (Note for each additional copy use the original file as the source for the copy)
4) Once you press OK in the dialog box the original and the last copy disappear.

If you don't recieve the above results then maybe my setup is at fault. But we have a support agreement with apple and they were able to reproduce this bug but I have yet to recieve a fix or an answer. I even installed 10.4.4 on client and server and it's still not fixed.

If anyone else has the same issue please report back to me. I know my test is something most users would not do but like I mentioned it can happen after the very first copy which in my case means that a student has lost their only copy of a document.

On a side note if you can reproduce this I have found that when the error message appears I don't press ok just yet but instead open a finder window and copy the original to an non afp volume. I then press ok and the file is still removed but the orignal is safe. Also this bug only applies to AFP mounted volumes/home directories. I cannot reproduce this when I log in with a local account.

Any help is appreciated.

Brad

iMac G5, Mac OS X (10.4.3), iSight

Posted on Jan 10, 2006 7:21 PM

Reply
Question marked as Best reply

Posted on Jan 24, 2006 9:04 AM

I can reproduce this with my setup. I have Mac OSX Server 10.4.4 on 3 servers running XSan 1.2. Users have AFP mounted home directories. I have tried this with clients running Mac OSX 10.4.3 and even tried 10.4.4. If I try to make a copy of a file in the same folder just by dragging and dropping, I'll get the permission error and the both files are gone. (anywhere in the mounted home dir)

Students have lost work doing this. Is Apple aware of this?
32 replies
Question marked as Best reply

Jan 24, 2006 9:04 AM in response to stjeanb

I can reproduce this with my setup. I have Mac OSX Server 10.4.4 on 3 servers running XSan 1.2. Users have AFP mounted home directories. I have tried this with clients running Mac OSX 10.4.3 and even tried 10.4.4. If I try to make a copy of a file in the same folder just by dragging and dropping, I'll get the permission error and the both files are gone. (anywhere in the mounted home dir)

Students have lost work doing this. Is Apple aware of this?

Jan 24, 2006 8:22 PM in response to llacasse

I have called Apple again and they still don't have an answer for me. Their standard response is we'll send it to engineering for a better look. Or it might be fixed in an update or new version 10.5? It seems every version fixes my previous bad bug but introduces a whole new set of bugs. I have yet to have a stable server platform. Thanks for taking the time to reproduce my problem. I hope Apple will resolve this soon.

Brad


iMac G5 Mac OS X (10.4.3) iSight

Mar 30, 2006 4:31 PM in response to stjeanb

We have the same problem.

We were origionally alerted to this problem becuase when selecting save in various applications ("Photoshop", "PowerPoint" ... ) the file would appear to have saved, however the file had not been saved, and in some cases the origional file was deleted.

When investigating these issues, we found that duplicating items in the finder also resulted in an intermittent error message being displayed "The operation cannot be completed because an item with name "xyz" already exists." When clicking the "OK" button to dismiss the message, the original file is deleted, and no the file is not duplicated.

Further investigation revealed that everything works fine in the Finder, until an application such as ( "TextEdit", "AppleWorks", "Word" or "PowerPoint" ) is launched and quit. From then on the Finder displays the error message intermitiantly when attempting to make duplications (COMMAND-D).

A pattern seems to be that the first time the error is displayed, the original file is not deleted but no duplicaiton occors. The second time the copy is not made and the original file is deleted.

We have setup from scratch a base 10.4.5 server and tested this with 10.4.4 and 10.4.5 client machines. So far the error has only been reproduced when dealing with files on a network home directory mounted via AFP.

The problem is not occurring if you mount the AFP share point using 'Go' : 'Connect to Server...' It only seems to occur when you login using an AFP mount-point as your home directory.

We are attempting to get apple involved to resolve this issue.

If anyone finds a fix/workaround to this issue please reply.

In addition, does sharing home directories via NFS fix this issue?

Apr 3, 2006 12:24 PM in response to stjeanb

OK, let's go with this. Several others are reporting the same problem:

http://discussions.apple.com/thread.jspa?threadID=428639&tstart=0

and

http://discussions.apple.com/thread.jspa?threadID=409444&tstart=0

And I've seen it, too. I originally reported this bug to Apple several months ago when 10.4.2 was released and here's my original posting: http://discussions.apple.com/thread.jspa?messageID=647624

So far, all I can say is the following:

1. The error message is not related to permissions being set incorrectly. As you've found out (or seen in the previous postings), you can use POSIX permissions or Tiger's Effective Permissions model, which incorporates ACLs.

2. The problem is specific to the Mac OS X 10.4.x Finder. Earlier Finders do not exhibit this problem. Attempting a copy (move or rename) via Terminal with cp, ditto, or mv is always successful.

3. I believe that the problem is related to the client's checking of permissions against stored directory information (checking for masked AFP permissions). You're more likely to get this error with a client that's bound to the server's Open Directory domain than one that's not.

4. I'm quite surprised that it's taken almost a year for this bug to really become discovered. I've noticed it right away and I think Apple has known about it for some time. I do think that the problem has gotten a little bit better with Mac OS X 10.4.4 and 10.4.5, but your mileage may vary.

I encourage you to keep posting details and filing Mac OS X Feedback reports ( http://www.apple.com/feedback/server.html). Maybe we can find a solution or Apple will take notice. 🙂

--Gerrit

Apr 30, 2006 4:03 PM in response to helpdesk

FOLLOW UP FROM APPLE

Called apple back - they have provided : a workaround ( not a fix ).

For us this is fantastic, depending upon your attachment to spotlight, you will be able to decide weather you will implement this workaround.

STEPS ( *ON THE CLIENT *)

(1) Open the following file : /etc/hostconfig

(2) Change the line "SPOTLIGHT=-YES-" to "SPOTLIGHT=-NO-"

(3) Reboot

Spotlight will be disabled however your files should stop vanishing.
Thank you very much apple. We are happy that there is now a workaround, people were losing work. Now we can rest easy. Thank you.

PS : TESTED ON 10.4.5 Client and Server
Upgrading to 10.4.6 Server stopped login working before this
workaround was applied to the clients.
It seems people have had mixed results with the 10.4.6 upgrade.
Be prepared to roll back to 10.4.5 if you are applying this upgrade.

Hope that helps.

Mac OS X (10.4.5)

May 14, 2006 2:34 PM in response to helpdesk

Follow Up From Apple

Apple suggests Spotlight is disabled on the server. As it appears to be enabled by default on the Tiger Server.

Simply follow the instructions within the post above to disable Spotlight on the Server rather than the client.

As always it is a good idea to make a backup, just incase something 'bad' happens. eg. 'sudo ditto -rsrc /etc/hostconfig /etc/hostconfig.orig'

Once the hostconfig file is modified and the server has been rebooted. Spotlight should be disabled on the server and you should find that Spotlight can be re-enabled on the client machines, and files will not be deleted, when selecting duplicated in the finder.

Everything should also work faster, as the server is now not attempting to index files as they are created. ( at least 2x faster )

So - the word from apple is that generally Spotlight should be disabled on the server. A little serendipity results in the duplication problem also being resolved.

We are happy with this, and all the entire system is faster.

May 14, 2006 9:25 PM in response to helpdesk

With any new or Erase & Install-type installation of Mac OS X Server, Spotlight is automatically disabled as per a "SPOTLIGHT=-NO-" entry in /etc/hostconfig.

Does disabling Spotlight on the client produce any changes for others? It's an interesting possibility that I hadn't considered, but it would be plausible: it's one thing that's "different" from 10.3.

--Gerrit

Jun 21, 2006 9:04 PM in response to Stephane Laroye

Have you attempted to disable Spotlight on the server?
Please let everyone know if this is still a problem.

Spotlight is on by default if you install from a 10.4.3 install disk.

Try disabling spotlight and see if this is still a problem....
Hope this sorts the problem out for you.

NOTE : If you are running photoshop 8.0 consider disabling spotlight on the clients, in addition to the server.

Jun 28, 2006 8:56 AM in response to Stephane Laroye

I can confirm this bug. Users have lost many critical
files now ⚠ even after telling them to avoid using
the Finder:Duplicate.


Help may be here! 10.4.7 for client and server is released. It is "supposed" to address this issue that we too have been having. From the Apple doc http://docs.info.apple.com/article.html?artnum=303687
Apple File Services (Client)
Addresses an issue that could cause files to be deleted when duplicating them in the Finder on a mounted AFP volume.



xserve with lab Imac 350+ emac 800+ 10.3.9 * 10.4 Mac OS X (10.4.5)

Jun 30, 2006 3:51 AM in response to poko

I can confirm this. Client is 10.4.7 (spotlight enabled), XServe is 10.3.9 (so no spotlight). The clients homedirectory is on the Xserve. In fact, it is a AFP reshare of a NFS mounted volume residing on a SUN.

HOWEVER: I could not reproduce this on a HELIOS Ethershare AFP volume I mount from the SUN directly. So, there must be a relation between OSX client and OSX server...

Jun 30, 2006 2:38 PM in response to gerd muller

Anyone try this where the server has been updated to Mac OS X Server 10.4.7 and the client has been updated to 10.4.7?

The Helios Ethershare software uses AFP 2.x, Mac OS X Server 10.3/10.4 uses AFP 3.2, so that's probably one of the differences. AFP 3 uses a strict POSIX or Effective (POSIX+ACL) permissions model, where AFP 2 uses a model that is based off of POSIX permissions, but works slightly differently (for example, new file POSIX permissions aren't set by umask).

--Gerrit

10.4.x Finder bug with AFP mounted home directory during a copy

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.