I have a RPi running a server to which I wish to transfer some SSL certificate files to be able to establish a secure connection from a browser. I presently have connected headless to the RPi from an OSX10.11 terminal window on my Mac using ssh to successfully create a root password (can login to the root account from that terminal).

An earlier post Copy files from OSX to/from Pi suggested, as the top answer, that Mac users could install the Appletalk protocol on the RPi using 'netatalk' and then use the Finder command in OSX, Connect to Server using afp://192.168.xxx.yyy to drag/drop the files onto the RPi. Moving files to the pi account proved very successful with the pi user credentials in the afp login window on the Mac. However, I cannot use the root user credentials to establish the connection.

I am aware that use of the root user has security implications, but I have a small trusted group of networked Macs behind a secure firewall and only intended to allow the connection for as long as it took to move the ssl certificate files directly into the necessary apache root directories on the RPi before returning to the Mac ssh terminal window to complete the SSL configuration.

The question is why can't I do this rather than moving the files twice via the pi user account?

  • 1
    It might be many reasons. You will find out by checking your error log on raspberry. It is probably located in /var/log/auth.log. There should be reason for rejecting your login. – Jakuje Dec 29 '15 at 16:28
  • You cannot access / in afp. If you edit /etc/netatalk/AppleVolumes.default you can access other directories e.g. I have :PIROOT: options:upriv,usedots,ro /etc "$hRoot" – Milliways Dec 29 '15 at 23:06
  • Hello and welcome. Could you please edit title and body of the question to clarify your intent? Right now the title reads that the osx is not accepting some password while the question suggests that you're talking about some kind of a login to the Pi - which suggests that the Mac got nothing to "accept" at all. Please do also note that the reference to an "earlier post" and a "top reply" is essentially impossible to follow. – Ghanima Dec 30 '15 at 0:43

"am unable to connect as user 'root' to move ssl certificate files directly into the root directories and would like to know why not?"

It is inadvisable (and unnecessary) to enable root. Even if you could, this approach will not work, due to a number of security and permission errors.

Copy the files to somewhere in /home, then login to the Pi (using ssh or directly) and move/copy the files.

If you are trying to copy ssl certificates even this is unlikely to work. You should tar the certificate files, then on the Pi untar to the desired destination. I use this procedure when setting up new Pi images.

  • 2
    Having clarified my intentions, I am prepared to accept that any security implications will have to dominate and prevent what I was attempting and thank you for the answer. – mfh Dec 30 '15 at 23:48

I suspect that your Mac, like many *nix systems has the root user's account explicitly disabled as a target for SSH login. This is because the root user is an obvious target for intrusion and brute-force login attempts, the usual recommendation is to log in as a normal user and sudo or su as appropriate for the task required. The RPi may or may not have this feature set - on rereading you post I am not so sure which machine is not accepting the remote SSH root login. In configuration terms look for an uncommented PermitRootLogin no line in the /etc/ssh/sshd_config on either Mac or Pi, which ever is the target in your SSH attempt (assuming that is where Apple puts the file...)

Just consider carefully why you want to remove this line of defence before changing it!


To have access to folders above home ~/ following file sudo nano /etc/netatalk/AppleVolumes.default and add to the line

~/                       "Home Directory"


~/                       "Home Directory"
/var                     "Webserver Stuff"

The next time you afp, you'll be given an option. You can have both open at the same time.

Also, you can try giving yourself root access:

/                     "Root with little access"
/root                     "Completely blocked Root"

But neither of the above really help much.


The code in NetATalk specifically inhibits the use of "root" to login across AppleTalk from the Mac to the Raspberry PI or any other UNIX system.

Very specifically the lines of code in Netatalk that inhibit this are in the auth.c file under GitHub on line 224 (as of this note date/time)

To get the root account able to login you would have to recompile Netatalk with line 224 changed from:

if ( pwd->pw_uid == 0 ) {   /* don't allow root login */


if ( pwd->pw_uid == 0 && (1 == 0) ) {   /* allow root login */

Adding the improbability 1 == 0 documents what you did while leaving the code intact and allows you to perform a code compare later to see it against a new version of the same source file.

Oh yes, not for the feint of heart... It might be easier to enable Access Control Lists (ACLs) in the file system and then apply an ACL to everything you want to modify. Netatalk appears to handle ACLs per the settings and conf files. TBD

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.