Bug #1699

AFPD issues

Added by behold5469 - about 8 years ago. Updated about 8 years ago.

Nice to have
Target version:
Seen in:
Reason for Closing:
Reason for Blocked:
Needs QA:
Needs Doc:
Needs Merging:
Needs Automation:
Support Suite Ticket:
Hardware Configuration:
ChangeLog Required:


I'm running into minor issues with the AFP shares. This has to do with the dynamic creation of the [[AppleVolumes]].default.

1) If I set the AFP3 checkbox I'm able to select the default permissions for file/directory creation (see screenshot 1). But the [[AppleVolumes]].default file doesn't get generated correctly, since I get:

"/mnt/Backup" "Backup_Files" options:usedots,upriv dperm:0 fperm:0

actually this should be dperm:07550 fperm:07550


2) In the console I get a message

volume "TimeMachine" does not support Extended Attributes, using ea:ad instead

googleing and finding this:
it seems that the "ea" flag should be set as a DEFAULT or for the individual share




#1 Updated by William Grzybowski about 8 years ago

Tiff? Can you please update using png or jpg? :)


#2 Updated by William Grzybowski about 8 years ago

Also, are you sure you're not hitting #1652 bug for 1)?
Can you change permissions using GUI?

#3 Updated by behold5469 - about 8 years ago

I've just done some experimenting and my issue (1) is obsolete. I've always used the "default" values 755. And the default can be depicted with a 0. If I change it say to 600 then dperm and fperm are generated correctly .... my mistake. Therefore the screenshot is unnecessary (sorry about the tiff, my "save as" messed up :-) )

Only my issue (2) should be considered.


#4 Updated by William Grzybowski about 8 years ago

Well, (2) seems rather a warning than an issue... or does it fix anything for you?

#5 Updated by MMX - about 8 years ago

I have issue 1) from original poster on my system.

System info:
Build FreeNAS-8.2.0-RELEASE-p1-x64 (r11950)
Platform Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz
Memory 8168MB
System Time Fri Aug 10 15:19:05 ICT 2012

I've attached a screenshot of the AFP permissions settings. They are all blank because that's what they revert to after I click all the boxes I want and then click the save button.

The permissions on newly created directories look like this:
drwxr-sr-x 3 user1 council 3 Aug 10 11:00 untitled folder 3/

I want group write access (775) , but the AFP3 UNIX Privs settings doing seem to be propagating into the [[AppleVolumes]].default file.

Look here too:
cat /usr/local/etc/AppleVolumes.default

  1. "/mnt/tank10/docs" "Documents" options:usedots,upriv dperm:0 fperm:0 allow:@council,@kadmin rwlist:@council,@kadmin

  2. "/mnt/tank10/admin" "Admin" options:usedots,upriv dperm:0 fperm:0 allow:@intops,@council,@kadmin rwlist:@intops,@council,@kadmin

  3. "/mnt/tank10/media" "Multimedia" options:usedots,upriv dperm:0 fperm:0 allow:@council,@kadmin rolist:@kadmin rwlist:@council

  4. "/mnt/tank10/shared" "Shared" options:usedots,upriv dperm:0660 fperm:0770 allow:anybody,@all,@council rolist:anybody rwlist:@council,@all

#6 Updated by MMX - about 8 years ago

I discovered a new clue to this problem.

1. Deselect AFP3 Unix Privs checkbox in AFP Shares settings for a share called "Docs"
2. Save
3. Open dialog again and select AFP3 Unix Privs checkbox and then select the file mask bits I want in "Default file permissions" and "Default Directory permissions"
3. Save
4. Check [[AppleVolumes]].default it looks like this:

cat /usr/local/etc/AppleVolumes.default
"/mnt/tank10/docs" "Documents" options:usedots,upriv dperm:0775 fperm:0777 allow:@council,@kadmin rwlist:@council,@kadmin

5. Open dialog again (notice all default permissions checkboxes are still checked) and then click "Save" without doing anything
6. Open dialog again and notice that the file mask bit check boxes are all de-selected, and the Applevolumes.default file looks like this.

cat /usr/local/etc/AppleVolumes.default
"/mnt/tank10/docs" "Documents" options:usedots,upriv dperm:0 fperm:0 allow:@council,@kadmin rwlist:@council,@kadmin

#7 Updated by William Grzybowski about 8 years ago

  • Status changed from Unscreened to Closed

Issue 1) has been fixed in another ticket and 2) is a warning which I am not willing to change because it seems to be a warning, not harmful, and I dont want to cause any sort of regression.

Feel free to reopen if thats a real issue.

Also available in: Atom PDF