AFP Time Machine Sharing

[MtK]

I followed the docs to the T and I haven't had any problems whatsoever. I suggest starting from zero and following the docs.

What version FreeNAS are you on?

Your individual time machine datasets should lie in the root of your volume.
e.g.
/mnt/Storage/TimeMachine1
/mnt/Storage/TimeMachine2
etc...

I really don't understand why the TM dataset needs to be in root (it is not explained and/or written anywhere) but I tried:

Code:

/# zfs list | grep Time
Storage/TimeMachine                                      1.11M  1.58T  1.11M  /mnt/Storage/TimeMachine

and I created a direct share here.

what I did notice was:

Code:

Mar  3 10:42:10 FN afpd[38080]: AFP logout by mtk
Mar  3 10:42:10 FN afpd[38080]: dsi_stream_read: len:0, unexpected EOF
Mar  3 10:42:10 FN afpd[38080]: afp_over_dsi: client logged out, terminating DSI session
Mar  3 10:42:10 FN afpd[38080]: AFP statistics: 0.82 KB read, 0.69 KB written

and the most important part is that TM is not working...

 

[MtK]

so... now backups see to work just fine, both manually ("backup now") and hourly started by the machine.
then I rebooted the Mac and:

 

[MtK]

Any ideas?

 

[adrianwi]

Have you got separate shares set-up for each Time Machine dataset or is the AFP share pointing at a higher level?

 

[MtK]

Have you got separate shares set-up for each Time Machine dataset or is the AFP share pointing at a higher level?

As suggested (which I still don't understand why) I have one dataset in the root of the pool Storage/TimeMachine, for a single user using it...

 

[adrianwi]

So do you have a share at the storage level or at the time machine level?


Sent from my iPhone using Tapatalk

 

[MtK]

So do you have a share at the storage level or at the time machine level?


Sent from my iPhone using Tapatalk

Timemachine (=dataset) level

 

[adrianwi]

Post a screenshot of the share set-up from the FreeNAS GUI, like this one:

 

[MtK]

If it's not here already I'll post it later...

 

[MtK]

here you go

 

[adrianwi]

Not sure if it's necessary, but mine has users assigned and I'm not having any problems. Might be worth a try?

And although it's probably nothing to do with the name, I'd call the dataset something other than TimeMachine.

 

[rogerh]

The error in the second post above look like some kind of AFP name service errors, which I don't know much about. But if you use the IP address of the FreeNAS machine in Time Machine (assuming it lets you) does this persist across a reboot? If so, it at least narrows the problem down. But not having the relevant user and group 'allowed' in the AFP share description may well affect this, as Adrian Williamson says above.

 

[MtK]

The error in the second post above look like some kind of AFP name service errors, which I don't know much about. But if you use the IP address of the FreeNAS machine in Time Machine (assuming it lets you) does this persist across a reboot? If so, it at least narrows the problem down. But not having the relevant user and group 'allowed' in the AFP share description may well affect this, as Adrian Williamson says above.

The group of users is set in the allow, I just removed it for the screenshot.
Don't forget we are talking about a single user here...

 

[MtK]

well, I just tried to make a backup, after turning one of the three jails off (a standard jail) and... the backup actually started!
which is really weird cause I already tried stopping all the jails and see if it has any affect but it didn't seem to. so I left them on.

I'm still suspecting something to do with the AFPd service, but I can't pin-point it...

 

[MtK]

well, not really working:

Code:

Mar  6 11:49:10 FN afpd[88534]: AFP logout by mtk
Mar  6 11:49:10 FN afpd[88534]: AFP statistics: 9870200.18 KB read, 398752.27 KB written
Mar  6 11:49:10 FN afpd[88534]: done
Mar  6 12:35:51 FN afpd[13746]: Login by mtk (AFP3.4)
Mar  6 12:35:51 FN afpd[13746]: afp_disconnect: trying primary reconnect
Mar  6 12:35:51 FN afpd[15801]: Reconnect: transfering session to child[33446]
Mar  6 12:35:51 FN afpd[15801]: Reconnect: killing new session child[13746] after transfer
Mar  6 12:35:51 FN afpd[33446]: afp_dsi_transfer_session: succesfull primary reconnect
Mar  6 12:35:58 FN afpd[13746]: afp_disconnect: primary reconnect succeeded

 

[diedrichg]

Here are my settings:

Group: time-machine
User: timemachine > Primary Group: time-machine

Volume: /mnt/dvgmar
with root/wheel as owners
Owner=rwe
Group=r-e
Other=r-e

Dataset: time_machine1 and time_machine2
user = timemachine
group = time-machine
Owner = rwe
Group = rwe
Other = ---

AFP:
two of them named = timemachine1 and timemachine2
path = /mnt/dvgmar/time_machine1 and /mnt/dvgmar/time_machine2
Allow List = @time-machine
Read-write access = @time-machine
Time Machine = checked
AFP3 Unix Privs = checked
Default file perms:
Owner = rwe
Group = rwe
Other = r-e
Default directory:
Owner = rw-
Group = rw-
Other = r--

 

[MtK]

back to this, with a (somehow) new issue....

 

[MtK]

This is what the log has to say about it:

Code:

Mar 19 09:02:36 FN afpd[2934]: Terminated disconnected child[98509], client rebooted.

 

[mharvey500]

Here are my settings:

Group: time-machine
User: timemachine > Primary Group: time-machine

Volume: /mnt/dvgmar
with root/wheel as owners
Owner=rwe
Group=r-e
Other=r-e

Dataset: time_machine1 and time_machine2
user = timemachine
group = time-machine
Owner = rwe
Group = rwe
Other = ---

AFP:
two of them named = timemachine1 and timemachine2
path = /mnt/dvgmar/time_machine1 and /mnt/dvgmar/time_machine2
Allow List = @time-machine
Read-write access = @time-machine
Time Machine = checked
AFP3 Unix Privs = checked
Default file perms:
Owner = rwe
Group = rwe
Other = r-e
Default directory:
Owner = rw-
Group = rw-
Other = r--

From my experience the latest Yosemite 10.10.3 does not find these settings. It does however find and backup to the shares created by the latest FreeNAS 9.3 wizard, which gives execute permissions to the AFP default directory.

 

[adrianwi]

No problems with my TM backups pre and post 10.10.3