Apple Event: May 7th at 7 am PT

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

Level 1

0 points

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

Best reply

llacasse

Level 1

5 points

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?

View in context

32 replies

Jul 4, 2006 2:54 AM in response to Gerrit DeWitt

I have just tested this issue on 10.4.7 server with 10.4.7 clients.

The bug is still there. After about 35 copies the original and the latest copy just disappeared!

Mac OS X (10.4.7) Apple Certified Technical Coordinator

Jul 4, 2006 3:00 AM in response to Gerrit DeWitt

The Helios Ethershare software uses AFP 2.x,

Depends on the version. EtherShare supports AFP 3.1 since approx. 2 years now (publicicly available 'AFP 3.1 preview' for EtherShare 3.1). The UB version (released at the end of last year) included AFP 3.1 support from the very beginning.

The following table might be of interest (sorry, available currently in german only): http://tiffy.ath.cx:8060/afp-server-vergleich.php

Mac OS X Server 10.3/10.4 uses AFP 3.2

AFP 3.2 came with 10.4. But the only relevant differences between AFP 3.1 and 3.2 are the support of ACLs at the AFP protocol layer.

so that's probably one of the differences. AFP 3 uses a strict POSIX or
Effective (POSIX+ACL) permissions model

No, it depends. If you disabled 'unix privileges' in favour of 'inherited privileges' then you don't get POSIX but instead 'classic' semantics.

Regards,

Thomas

Jul 6, 2006 9:56 PM in response to Thomas Kaiser

Good catch on the AFP 3.1 support for Ethershare. That was my mistake!

And you're right about AFP 3.2 being first used in 10.4. I think 3.1.1 was used in 10.3, and 3.1 was introduced with 10.2.

> so that's probably one of the differences. AFP 3 uses a strict POSIX or

Effective (POSIX+ACL) permissions model

No, it depends. If you disabled 'unix privileges' in favour of 'inherited privileges' then you don't get POSIX but instead 'classic' semantics.

I think we're misunderstanding each other here. We both know that you can use POSIX permissions (ACLs disabled) or enable ACLs and use the ACLs+POSIX Effective Permissions model. That's just a filesystem-level change - ACLs off or on.

But I'm curious about what you mean here. With ACLs disabled, there's the option to use the "Inherit Permissions from Parent" AFP model, which I believe writes sets afp use_parentprivs to 1 for the chosen share in the /config/SharePoints/share record in the local NetInfo domain.

What I was referring to was the fact that AFP 2.2 does not technically use a POSIX permissions model, while AFP 3.x does. Namely, umask isn't consulted for the POSIX bits assigned to newly-created files/folders. In AFP 2.2, that information was inherited from the folder's parent. I'm referencing this Apple document: http://docs.info.apple.com/article.html?artnum=107326, which explains why AFP 3.x is required for Mac OS X home directory use, and Apple File Services Admin Guide which mandates that the Inherit Permissions from Parent AFP option not be used for home directories. That's what I mean when saying that AFP 3.x uses a strict POSIX model. I know that it has the 2.2-like Inherit option on a per-share point basis.

Are you referring to the permissions_model property in the com.apple.AppleFileServer.plist file? That can be unix_permissions or classic_permissions, which I think emulates AFP 2.2 behavior on a server-wide level. Helios Ethershare calls classic_permissions "smart permissions" I think, but I'm not really familiar with Ethershare.

Do I understand you correctly?

--Gerrit

MacSEK

Level 1

10 points

Jul 27, 2006 5:38 AM in response to stjeanb

Does anybody try to disable spotlight on Mac OS X Server 10.4.7? We have some strange problems using AFP shared homedirectories and other AFP sharepoints on two OD Replikas (saving Problmes with Office and stuff). So i think about disabling spotlight at any server even in case i only get some more performance on my servers.

Could disabling spotlight on the servers cause any other strange behavior? Mayby affecting the OD / LDAP, AFP or anything else?

MacSEK

Jul 28, 2006 3:55 AM in response to MacSEK

I've just turned Spotlite off on our 10.4.7 Server. However, can't reboot yet as too many users logged in and I wouldn't be popular!

Will reboot later tonight for the change to take effect and let you know the outcome.

Jul 29, 2006 3:46 AM in response to Jack of all trades

Happy to report this getround appears to work fine. Rebooted the x.4.7 server, logged in to server AFP share from x.4.7 client, using MS AD authentication. All machines are bound to MS AD.

Client could now duplicate files to same folder or anywhere else in same volume with no problems.

Re-checked hostconfig, still says SPOTLIGHT=-NO-

We'll see whether there are any side effects, or if it somehow creeps back in. So far so good though 🙂

Aug 9, 2006 12:36 AM in response to stjeanb

I have to come back on this. Does anybody solved this problem without disabling Spotlight?
I just installed from scratch a new client with 10.4 and then combo update to 10.4.7. The server is on 10.3.9, so no Spotlight there. When I login with a network user, file duplication fails.

BUT: if I mount the same home directory with command-k via AFP as a "normal" AFP mount, file duplication never fails! Same client, same server, same data! Isn't this funny?

Gerd

Mac OS X (10.4.7)

Aug 11, 2006 6:39 AM in response to gerd muller

So: Users with AFP mounted home directories have the choice of loosing files or disable spotlight?? C'mon Apple: FIX THIS, but subito, please!

llacasse

Level 1

5 points

Aug 14, 2006 12:54 PM in response to stjeanb

I can confirm that by disabling spotlight on the server DOES NOT fix this issue. However disabling spotlight on the workstation so far, as been working 100% reliable. (this with duplicating a simple text file on an AFP mounted home directory using MacOS X Server 10.4.7 and MacOS X 10.4.7 on the workstation using XSan 1.3)

I will do further testing with other apps.

Sep 24, 2006 11:51 PM in response to llacasse

Just confirming, same problem. I too noticed this back with 10.4.2 clients on 10.3.x servers. Back then I foolishly blamed the 10.3.x server and so did an Apple tech that convinced me to upgrade our servers.

So this school year we have all 10.4.7 servers and more 10.4.7 clients. However this issue of dropped files is killing me! I still have a few labs of 10.3.9 and they never show this problem.

Spotlight was enabled on my servers. Turning this off appeared to slow down the frequency of this error. However, I had to turn it off on the 10.4.7 clients to really stop this.

Odd this hasn't been fixed by Apple

jtmunier

Level 1

5 points

Nov 7, 2006 6:46 AM in response to Jonathan Konrad

Hello everybody,

I have the same problem at work, just I can say in OS X 10.4.8 environnement (servers+ clients) nothing have change, i must disable spotlight for network user who acces to their home folder by AFP because duplicate and copy failed and erase original data some time.

I hope Apple could resolve it soonly.

Have a great fun day...

JT

Nov 20, 2006 8:18 AM in response to stjeanb

can confirm disabling Spotlight on the CLIENT stops the duplicate/copy vanishing trick with immediate effect. But what's the long term solution? :-\

Currently OS X Server: 10.3.9
Variety of clients: 10.4.x: 10.4.7, 10.4.8 have successfully been turned off and tested with immediate effect.

Don't seem to suffer the problem on 10.3.x clients!

Also have a 10.4 server waiting in the wings...but want to know if its worth rolling out considering this outstanding problem

TIA

Dec 9, 2006 1:49 PM in response to havinabubble

That's good to hear confirmation. As I had suspected, this problem was client-side.

Unfortunately, the fix may be Mac OS X 10.5. Fortunately, that's only a few months away.

If you haven't bought Apple Maintenance Program licenses, now would be a good time to do so - they provide current Mac OS X releases for three years!

--Gerrit

Dec 20, 2006 3:03 PM in response to havinabubble

Sorry to dumb this thread down, but what will turning off Spotlight lose me? Will that mean I'll lose search functionality, or just lose the search feature in the top right corner? We use searching quite a lot here across our servers to find files across all servers instead of manualls hunting for them so I don't want to lose that!

I'm trying to solve the bug of when in Photoshop we go to save a file located in a NHD and it says it can't because "write access was not granted" and I'm hoping this might do it.

Thanks!

MacSEK

Level 1

10 points

Dec 20, 2006 11:07 PM in response to stjeanb

Disabling Spotlight will disable the search at all. So when spotlight is disabled, and you do s simple search inside Finder (for example to search a file on an AFP sharepoint), you will get no results.

MacSEK

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