Project

General

Profile

Bug #15239

can't create files on AFP share

Added by D Dobkin over 4 years ago. Updated about 3 years ago.

Status:
Closed: Cannot reproduce
Priority:
Nice to have
Assignee:
Vaibhav Chauhan
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Configuration:

Using AFP shares authenticated to Open Directory/LDAP.

Summary:

Authenticating to a workstation and FreeNAS with the same UID fails in some cases; authenticating with different UIDs with the same access privy to the FreeNAS shares succeeds in all cases.

Example:

When logged in to an OD-bound workstation as user "rob" and authenticating to FreeNAS as user "rob" we can properly open, save, duplicate files in /mnt/pool/arbitrary/path/to/file. we CANNOT create a new file by dragging from the Desktop and dropping on the same folder in the Finder. Entries in daemon.log are of the form

afp_setacl("/mnt/pool/arbitrary/path/to/file"): error

with no additional information. (Probably time to set a debug logging level for AFP service.)

"Save As..." from Word or other program to the same file does work. Copying from the command line also works.

Logging in to the OD workstation as "rob" and authenticating to FreeNAS as user "chuck" allows all operations to complete as expected.

(This is the bad news; the good news is that FreeNAS significantly outperforms OS X Server in every other way that our users care about.)

History

#1 Updated by D Dobkin over 4 years ago

  • File debug-files-20160509093125.txz added

#2 Updated by Suraj Ravichandran over 4 years ago

  • Assignee changed from Suraj Ravichandran to Vaibhav Chauhan
  • Target version set to Unspecified

Over to Vaibhav since he is testing the other AFP stuff too.

#3 Updated by Vaibhav Chauhan over 4 years ago

  • Status changed from Unscreened to Screened
  • Priority changed from No priority to Nice to have

#4 Updated by Vaibhav Chauhan over 4 years ago

  • Seen in changed from Unspecified to 9.10-STABLE-201605021851

#5 Updated by D Dobkin over 4 years ago

Thinking out loud: while it is not (at present) our use case, this is a real problem where home folders are on the freeNAS AFP share. We've worked around it by adding a bogus user to authenticate the freeNAS mounts -- but for home folders, or in an environment where knowing who last wrote the file is important, this is probably more than "nice to have." Just sayin'.... because I'd dearly like to ditch Apple's file server completely. The headaches become more evident with each new OS X Server release.

#6 Updated by Vaibhav Chauhan about 4 years ago

  • Seen in changed from 9.10-STABLE-201605021851 to Unspecified

I will work on it and get it done.

#7 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Seen in changed from Unspecified to N/A

#8 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to 9.10.1-U1

#9 Updated by Dru Lavigne about 4 years ago

VB, will this be fixed in time for U1?

#10 Updated by Vaibhav Chauhan about 4 years ago

  • Status changed from Screened to Closed: Cannot reproduce
  • Target version changed from 9.10.1-U1 to 9.10.1-U2

I have not been able to reproduce this issue. closing out

#11 Updated by Dru Lavigne about 3 years ago

  • File deleted (debug-files-20160509093125.txz)

#12 Updated by Dru Lavigne about 3 years ago

  • Private changed from Yes to No

Also available in: Atom PDF