#651 AFP won' t work through SSH tunnel

[Neko Chang]

Hi All

I wish backup MacBook 2018 @ MACOS 10.14 to my remote FreeBSD server.
So installed netatalk v3.1.12 into it.

And configuration afp.conf as below.
[Global]
hostname = epopen.com
vol preset = "Time Machine Volume, User=$u"
log level = default:maxdebug
cnid mysql host = localhost
cnid mysql db = DB
cnid mysql user = USER
cnid mysql pw = PASSWORD

[Homes]
basedir regex = /home

[Time Machine Volume, User=$u]
cnid scheme = mysql
ea = ad
valid users = @timecapsule
path = /home/time-capsule/$u
time machine = yes

Here:
1. epopen.com is my remote FreeBSD server.
2. Create a user:BAR password: FOO for backup, and it's group = timecapsule.
2. Path /home/time-capsule is ZFS dataset.
3. Created empty database named DB in MySQL server.

Create SSH tunnel as below.
/usr/bin/ssh -N -f -L 30548:epopen.com:548 SSHUSER@epopen.com

And use command in MacBook as below
% open afp://BAR:FOO@localhost:30548

I show "Select the volumes you want to mount on localhost:30548" and two volume shown:
1. BAR's home
2. Time Machine Volume, User=BAR.

After choose "Time Machine Volume, User=BAR".
Show /home/time-capsule/BAR's file/directory @ FreeBSD server in Finder.
Next, choose "Back Up now" @ Time Machine icon located in the OS X menubar.

Finally error dialog shown, detail reason as below picture.
https://forum.promise.com/content/uploads/fbf0a042-5a9b-4c8d-ad9f-a93800d10d9b/d5c4711e-8ee3-4c86-a535-a938016c6f78_detail2.jpg?width=690&upscale=false

In FreeBSD sever , /var/log/netatalk.log has strange error as below.
Mar 16 00:16:31.643171 afpd[86177] {afp_dsi.c:624} (debug:AFPDaemon): <== Start AFP command: AFP_LOGIN_EXT
Mar 16 00:16:31.643495 afpd[86177] {uams_dhx2_passwd.c:265} (info:UAMS): DHX2 login: BAR
Mar 16 00:16:32.124313 afpd[86177] {afp_dsi.c:633} (debug:AFPDaemon): ==> Finished AFP command: AFP_LOGIN_EXT -> AFPERR_AUTHCONT
Mar 16 00:16:32.173562 afpd[86177] {afp_dsi.c:624} (debug:AFPDaemon): <== Start AFP command: AFP_LOGINCONT
Mar 16 00:16:32.177721 afpd[86177] {afp_dsi.c:633} (debug:AFPDaemon): ==> Finished AFP command: AFP_LOGINCONT -> AFPERR_AUTHCONT

But work fine If connect DIRECTLY (without SSH tunnel) as
% open afp://BAR:FOO@epopen.com:548
I known it is dangerous due to non-encrypted so test only.

I don't konw misconfigure or bug.
Can help debug?
Thanks all very much.

[TROTEBAS ELIOTT]

Hello,

I think I have a similar issue here with el Capitain and Debian.

-I can connect with my finder as AFP client with no problem: I can write and read in the mounted volume.
-I can find the disk and add it into time machine, the time machine add the disk, know the available size
-But If I start the time machine fist backup there is a login error.

As you can see in the picture attached I have a "DHX2: PAM_Error: Authentication failure" error.
On the left its with AFP and on the right it's with time machine. Both have this error but only time machine fail (and not when the disk is attached at the first time).

But sometimes there is no error with AFP client, with or without error I can use the client:

Apr 11 23:20:36.298645 afpd[6062] {dsi_tcp.c:241} (info:DSI): AFP/TCP session from 127.0.0.1:50236
Apr 11 23:20:36.318538 afpd[6062] {uams_dhx2_pam.c:329} (info:UAMS): DHX2 login: eliott
Apr 11 23:20:36.416884 afpd[6062] {uams_dhx2_pam.c:214} (info:UAMS): PAM DHX2: PAM Success
Apr 11 23:20:36.475573 afpd[6062] {uams_dhx2_pam.c:709} (info:UAMS): DHX2: PAM Auth OK!
Apr 11 23:20:36.475737 afpd[6062] {auth.c:235} (note:AFPDaemon): Login by eliott (AFP3.4)

Full log login with AFP: https://pastebin.com/jBuqTsgg
Full log time machine login: https://pastebin.com/YADwpvg3

Netatalk config:

;
; Netatalk 3.x configuration file
;

[Global]
; Global server settings

 afp listen = 127.0.0.1
 dbus daemon = /usr/bin/dbus-daemon
 disconnect time = 3
 sleep time = 2
 log file = /var/log/netatalk.log
 log level = default:info
 uam list = uams_dhx2.so
 zeroconf = yes
 save password = yes

; [Homes]
; basedir regex = /xxxx

; [My AFP Volume]
; path = /path/to/volume

 [Time Machine Eliott]
path = /home/eliott/DATA
valid users = eliott
time machine = yes
unix priv = yes
file perm = 0600

Thank you for help.

[Daniel Markstedt]

The two reports don't seem to have much in common apart from both using TM volumes and both specifying the "valid users" parameter for the TM volume. Just as a troubleshooting step, does it make a difference if you remove that parameter? We've had known corner case scenarios with users and permissions over the years...

FWIW, I've been running a TM server with the latest main development code on Debian, and my Ventura MBP over the last 2 weeks with hourly backups and not had major issues, so it should be possible to get it to work.