Getting Serious about Permissions

This post has already been read 2889 times!

I had lots of fun last year for MARCHintosh and made available a basic AFP share via my raspberry pi and just pretty much dumped all my stuff there. I was never really happy with it that way and so I am in the process of organizing it and cleaning it up for better sharing – but I also realized it’s just not the best idea to expose all that on a open, Guest enabled share. Putting some basic permissions on the folders and files to ensure no funny business made more sense the more time I’ve invested in them.

With that in mind, I decided to Get Serious about Permissions.

This guide will take you thru some steps to do the same. My assumptions here are: using Netatalk 2.x (the OG, with afp compiled into the kernel) on a linux-based system – in my case a Pi. This however will work with any Netatalk version I’m pretty sure- the point is using linux based file permissions, nothing inside netatalk save from basic options for the Volumes. I also hope you have another Classic Mac (physical or emulation) locally on your network to test the mounting of the volumes via the Chooser, as well as a modern Macintosh you will mount via TCP/IP. The system I’m lucky enough to work with are:

1. Quadra 800 acting as the AIR
2. RasperryPi 4 as the AFP server (it’s a RASCSI not doing any scsi work)
3. Quadra 605 – my classic Mac, for running and playing with things
4. Mini – my modern Mac, for getting it done.

The kernel info for my afp server


pi@rascsi1:/etc/netatalk $ uname -a
Linux rascsi1 5.15.56-v7l-netatalk+ #2 SMP Sun Aug 21 19:46:43 BST 2022 armv7l GNU/Linux


Securing MARCHintosh Shares with Proper UNIX Permissions

When setting up file shares on an AFP (Apple Filing Protocol) server, securing permissions properly is crucial to maintaining data integrity and preventing accidental or malicious file modifications. In this guide, we’ll walk through configuring read-only, write-only, and immutable permissions to ensure users can safely interact with shared folders while preventing unintended deletions or unauthorized modifications.

We’ll focus on two common scenarios:

A Public Share

• Drop Folder – where users can upload files, see other uploaded files but cannot delete or modify existing ones.
• Read-Only Folder – where users can view and copy files and archives but cannot edit, delete, or add new files.

A Private Share

• Normal files, but only accessible via the Chooser as a specific user on the pi.
• Guest access will never even see this share in the Chooser.

By leveraging chmod, chown, and special attributes like the sticky bit (1777) and immutable flag (chattr +i), we can enforce strict access control while keeping the AFP share functional and easy to use. This approach ensures a secure and controlled file-sharing environment, protecting valuable data from accidental loss while allowing the intended level of access for users.

Using Netatalk on Linux and Managing File Ownership

Netatalk is an open-source implementation of the Apple Filing Protocol (AFP), allowing macOS clients to connect seamlessly to Linux-based file shares. When running Netatalk on Linux, the AFP daemon (afpd) typically runs as root, but the actual files and folders are owned by a designated user—often a standard system user like pi in a Raspberry Pi setup. This distinction is crucial because while afpd needs elevated permissions to manage network shares, file access should be strictly controlled at the filesystem level to prevent unwanted modifications.

By properly setting ownership (chown) and permissions (chmod), we ensure that users can interact with shared directories without risking file deletions or unauthorized modifications. In a well-secured AFP setup, files are owned by a specific user (pi in our case), and folder permissions are configured to allow writing, reading, or restricted access as needed. Combining these settings with Netatalk’s built-in options ensures a balance between usability and security, preventing accidental data loss.

Controlling and Configuring afpd

First we should make sure we can stop and start the service, and watch what is going on with logs. Raspian on the Pi uses systemd and so we need some basic commands to control the service as well as output logs to see any issues.

$ sudo systemctl stop afpd.service
$ sudo systemctl start afpd.service
$ sudo systemctl restart afpd.service

$ sudo journalctl -fu afpd --no-pager

Some typical output of afp


Mar 03 18:04:20 rascsi1 afpd[26205]: session from 548.50:237 on 918.122:156
Mar 03 18:04:20 rascsi1 afpd[26205]: login noauth
Mar 03 18:04:20 rascsi1 afpd[26205]: AFPVersion 2.0 Login by nobody
Mar 03 18:04:21 rascsi1 afpd[26205]: 0.03KB read, 0.02KB written
Mar 03 18:04:21 rascsi1 afpd[26205]: done


Now that we can control the service and see what is going on- we need to define the volumes. I’m going to assume that you know how to install and setup netatalk 2.x and have a afp server startup on your EtherTalk network and you can see it with your Macs (via Chooser). I will focus on the volumes presented once a user has connected to your server – and setting the permissions for them in Linux so that your visitors can properly use the resources you are sharing on GlobalTalk for MARCHintosh or beyond.

Volume Setup and Lockdown

The config file that controls this is usually in /etc/netatalk and it’s called AppleVolumes.default.


$ cd /etc/netatalk
$ cat AppleVolumes.default


At the bottom of the file we want to define two Volumes (shares) one for GlobalTalk Guest access and one to hold our other files where we want to be able to manipulate them for local projects.

/home/pi/afpshare/Privates "Private" options:authonly,upriv,usedots allow:dillera

/home/pi/afpshare/Publics "Public" options:nofileid

dillera above is a linux user called ‘dillera’ that I created on the pi using adduser command. I use this user to ssh and become the pi user if I need to manage the server. I want to be able to authenticate to the afp server, via the Chooser, using this user – and the password I set for it. Beware that the Chooser sends this password in the clear, so either do this locally or if you are working with others and auth’ing across GlobalTalk make sure you have credentials that are not used for anything else in your projects.

Once you have edited this file make sure you restart afpd using systemd commands and watch the logs to ensure it has started up correctly.

$ sudo systemctl restart afpd.service

Lockdown Public Dropbox

Now we have our two shares defined, lets lock them down.

sudo chown -R pi:pi /home/pi/afpshare/Publics/Dropbox
sudo chmod 1777 /home/pi/afpshare/Publics/Dropbox

Explanation of chmod 1777:
• 1- Sticky bit (1XXX): Prevents users from deleting files they don’t own.
• 7- Owner (pi): Full control (rwx).
• 7- Group (pi): Full control (rwx).
• 7- Others (anyone): Read and write, but not delete (rwt).

Lockdown Public Folder for Shared Files

For the Shared folder on the public volume we will restrict it the pi user account.

sudo chown -R pi:pi /home/pi/afpshare/Publics/MARCHintosh

Then find all the directories (folders) changing their permissions properly. Find the files and do the same for them. The permissions are different in order to allow people to open the directories while browsing.

sudo find /home/pi/afpshare/Publics/MARCHintosh -type d -exec chmod 755 {} +
sudo find /home/pi/afpshare/Publics/MARCHintosh -type f -exec chmod 644 {} +

• Directories = 755 (Read, Execute for everyone; Write only for owner)
• Files = 644 (Read for everyone; Write only for owner)

Lockdown Private Volume

We won’t lock this down beyond ensuring all the files and folders are properly owned by the pi user. Since these files are for our use and we’ve connected as a registered user they should all be set read and writable. I’ll be moving a bunch more from here over to the public share as I finish organizing them.

Putting it into Action

Let’s look at this in action….

One thing you can do is set your username and password on your client Macintosh, this will save you time when you mount your Private share as your user.

Selecting the Appleshare Server

Connecting as Guest

Only the Public Share is Visible

No deletion of other files

Your files can be deleted

Read Only Folders

Connecting as a Registered User

Both shares are Visible as Registered User

Normal File access to the shares as Registered User

With this information you should be able to safely share data on GlobalTalk without worrying that you will wake up with it all gone due to bad actors.