Jump to content

HOW-TO: AFP announced over Avahi *READY*


dlmh

Recommended Posts

Timemachine backup for 3 Mac`s was one of the objectives of my unRaid server installation. This is why I highly appreciate dlmh`s description.

 

However some questions remain.

 

After the installation I had some issues with open files and unRaid was stuck with "UNMOUNT". I switched off the server and experienced always a Parity Check each time on reboot. This is fixed now but all the users except root have disappeared from web admin. Is there a way to have them back in the web admin? I even can't put them back - perhaps because they are still existing in the system? At least I'm able to connect under exactly those users names.

 

My second question is the following. I edited the following files according to dlmh`s guide.

1: /etc/passwd
2: /etc/shadow
3: /etc/netatalk/afpd.conf
4: /etc/netatalk/netatalk.conf
5: /etc/netatalk/AppleVolumes.default
6: /etc/avahi/services/samba.service
7: /etc/avahi/services/afpd.service

 

Everything's on the flash drive and it's correctly copied to the config files on boot.

 

passwd file:

user1:x:1007:100::/bin/bash
user2:x:1007:100::/bin/bash
user3:x:1007:100::/bin/bash

 

shadow file:

user1:{some.random.string}:14542:0:99999::::
user2:{some.random.string}:14542:0:99999::::
user3:{some.random.string}:14542:0:99999::::

 

Lastly I changed permissions:

chown -R user1:users /mnt/disk1
chmod -R 2775 /mnt/disk1
chmod -R 2770 /mnt/disk1

 

It seems that I always have to enter these permissions to get access via AFP. I just tried with disk1 and now I only have access to disk1 (..I can't even see disk2)

 

Is there any option available? Executing these commands at every reboot isn't feasible - takes forever...

 

Or maybe I'm wrong using the following entries in AppleVolumes.default?

/mnt/disk1 "disk1" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots perm:2770
/mnt/disk2 "disk2" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots perm:2770
/mnt/disk1/_TimeMachine "TimeMachine" allow:user1 cnidscheme:cdb options:upriv,usedots,tm perm:2770
/mnt/disk1/_TimeMachine "TimeMachine" allow:user2 cnidscheme:cdb options:upriv,usedots,tm perm:2770
/mnt/disk1/_TimeMachine "TimeMachine" allow:user3 cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

And honestly I don't know what the best entries are in the web admin under Shares respectively User Shares.

 

Sorry for having so many questions.....

 

Link to comment
  • Replies 69
  • Created
  • Last Reply

Hi, can anyone clarify if this method does or doesn't work with user shares? I use user shares such as Photos, Movies etc to make it easier for the wife and to add things to XBMC. If I can't get those to work then maybe I don't need to make the effort to set this up :)

 

Cheers,

 

Justin

Link to comment

Soul,

 

yes it´s working. I share all the movie, music and photo files via AFP plus Timemachine is working for all the users at home - also via AFP.

 

My remaining issue are the permissions I guess. But this might have to do with something else. I opened a new thread for this:

 

http://lime-technology.com/forum/index.php?topic=6326.msg61410#msg61410

 

Don´t forget to start with

defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

on your Mac console if you want to use Timemachine with unRAID.

Link to comment

ok thanks for that - I saw this bit in the how-to and got a bit worried:

 

Update: DO NOT share your User Shares, this creates a lot of errors in the database the AFP daemon uses.

 

Also there's a lot of stuff about changing all the permissions etc for all files on the server for AFP. What happens when you add new files to the server? Do you have to manually update every new file you add?

 

Cheers,

 

Justin

Link to comment

Honestly Justin - I don´t know.

 

I still have so many questions regarding the unRAID concept.

 

With SMB I do see e.g. my share MUSIC. According to the manual this share can be widespread across different discs. Until now it´s only on disc2 but as the music collection is growing it will start to be saved on other discs too - and I still see one share which is great because I can ignore the hardware boundaries. That´s how I understand the concept.

 

In AFP I don´t see the share. I see it as folder under disk2 but I can´t include it into the finder bar as I can with SMB....

 

So for us Mac users it would be great to have AFP as seamlessly integrated as SMB - but maybe I´m just not smart enough to understand how to use.

 

Cheers

Oliver

Link to comment

I have the same thing Oliver - Music, Photos and Movies shares that span multiple disks. I'm not sure that they're going to work under AFP (and you're not seeing them either).

 

So I've got as far as getting avahi to show my Tower in the Finder all the time, which is great, and I think that might be as far as I'll go..... I'm not sure the additional speed of afp is worth me hacking about to then find I can't use the user shares anyway :)

Link to comment

Hi I'm having trouble with the login part. When I try to log in to AFP, syslog says the following.

[pre]May 15 06:25:31 centax nss_wins[5451]: ASIP session:548(5) from 192.168.0.47:54970(8)

May 15 06:25:31 centax nss_wins[5451]: dhx login: matthew

May 15 06:25:31 centax nss_wins[5451]: uam_checkuser: User matthew does not have a shell

May 15 06:25:31 centax afpd[5451]: 0.09KB read, 0.05KB written

May 15 06:25:31 centax nss_wins[5445]: server_child[1] 5451 done

[/pre]

 

I set the shell to /usr/bin/bash, and get the following.

[pre]May 15 06:28:55 centax nss_wins[5475]: ASIP session:548(5) from 192.168.0.47:54998(8)

May 15 06:28:55 centax nss_wins[5475]: dhx login: matthew

May 15 06:28:55 centax nss_wins[5475]: illegal shell /usr/bin/bash for matthew

May 15 06:28:55 centax afpd[5475]: 0.09KB read, 0.05KB written

May 15 06:28:55 centax nss_wins[5445]: server_child[1] 5475 done

[/pre]

 

And similar when I set the shell to /bin/sh

 

Any ideas? Thanks (btw this is with the free unraid, and I added the matthew user manually on the cli)

Link to comment

I understand that adding a user share to AFP creates lots of errors.  What if, however, I just want to mount a user share in AFP for reading?  Would it still create errors?

 

Also, if I wanted to make the "UNRAID" user share available for reading in AFP, would adding the following to the AppleVolumes.default be correct?

 

/mnt/user/unraid "unraid" allow:[user] cnidscheme:cdb options:upriv,usedots perm:4440

 

Thanks in advance.

Link to comment
  • 1 month later...

And similar when I set the shell to /bin/sh

 

Any ideas? Thanks (btw this is with the free unraid, and I added the matthew user manually on the cli)

 

Well, it said in the how-to that the shell had to be set to /bin/bash ;)

 

For all others questions related to user shares:

 

The AFP daemon creates hidden files and folders in the root of every folder you visit through AFP. Because user shares could possibly span multiple disks, it's possible that when you visit the user share these files get created on only one of the disks. However, when you visit the disk share and the hidden files/folders are not there, the AFP daemon will create these files there also. Now, when you go back to the user share the daemon will choke because the unRAID filesystem presents only one, randomly chosen(?), instance of these files. You will also get errors in the syslog from shfs that it finds files with the same name on multiple disks.

 

About permissions:

 

If you set the permissions of a folder to 2xxx (e.g. 2775), all files and folders created in that folder will also have the same permissions. However, some applications and services do not respect that flag as they explicitly set the permissions and ownership to something different. Sabnzbd, for instance, creates files with their own permissions and owner root, while the usergroup will stay at users (instead of root). This will give you trouble renaming, deleting and moving files.

 

This is the reason I reverted to using Samba with Avahi. However, I only rarely copy from or to the unraid server directly, as most of the content consists of movies and tv shows downloaded through Sabnzbd, which runs on the same machine. If I were to regularly copy (large) files from or to unraid, you might consider still using AFP. You could also use FTP for this, as it's better suited for fast transfers than Samba and AFP.

Link to comment
  • 2 weeks later...

I didn´t changed my setup since Reply #18, March 25 and Reply #50, May 2.

 

I was never happy with the Time Machine backup (over WLAN) but since a couple of days it´s not working at all.

 

Here is the log:

 

Jul  6 12:30:25 Tower afpd[4397]: server_child[1] 17785 exited 1

Jul  6 12:30:25 Tower afpd[17786]: ASIP session:548(5) from 192.168.0.2:49397(7)

Jul  6 12:30:25 Tower afpd[4397]: server_child[1] 17786 done

Jul  6 12:30:25 Tower afpd[17787]: ASIP session:548(5) from 192.168.0.2:49398(7)

Jul  6 12:30:25 Tower afpd[17787]: dhx login: edgar

Jul  6 12:30:25 Tower afpd[17787]: login edgar (uid 1007, gid 100) AFP3.1

Jul  6 12:30:25 Tower afpd[17787]: afp_getsrvrparms(/mnt/disk1/_TimeMachine): stat: No such file or directory

Jul  6 12:30:26 Tower afpd[17787]: afp_getsrvrparms(/mnt/disk1/_TimeMachine): stat: No such file or directory

Jul  6 12:30:26 Tower afpd[17787]: Setting uid/gid to 1007/100

Jul  6 12:30:26 Tower afpd[17787]: CNID DB initialized using Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006)

Jul  6 12:30:26 Tower afpd[17787]: Setting uid/gid to 1007/100

Jul  6 12:32:06 Tower sshd[18309]: error: Could not get shadow information for root

Jul  6 12:32:06 Tower sshd[18309]: Accepted password for root from 192.168.0.2 port 49420 ssh2

Jul  6 12:32:06 Tower sshd[18386]: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory

Jul  6 12:32:06 Tower sshd[18386]: lastlog_openseek: /var/log/lastlog is not a file or directory!

Jul  6 12:32:06 Tower sshd[18386]: lastlog_filetype: Couldn't stat /var/log/lastlog: No such file or directory

Jul  6 12:32:06 Tower sshd[18386]: lastlog_openseek: /var/log/lastlog is not a file or directory!

Jul  6 12:33:28 Tower afpd[18536]: ASIP session:548(5) from 192.168.0.2:49434(7)

Jul  6 12:33:28 Tower afpd[4397]: server_child[1] 18536 done

Jul  6 12:33:28 Tower afpd[18537]: ASIP session:548(5) from 192.168.0.2:49435(7)

Jul  6 12:33:28 Tower afpd[18537]: dhx login: edgar

Jul  6 12:33:28 Tower afpd[18537]: login oliver (uid 1007, gid 100) AFP3.1

Jul  6 12:33:28 Tower afpd[18537]: afp_getsrvrparms(/mnt/disk1/_TimeMachine): stat: No such file or directory

Jul  6 12:33:28 Tower afpd[18537]: Setting uid/gid to 1007/100

Jul  6 12:33:28 Tower afpd[18537]: CNID DB initialized using Sleepycat Software: Berkeley DB 4.4.20: (January 10, 2006)

Jul  6 12:33:32 Tower afpd[18537]: afp_getsrvrparms(/mnt/disk1/_TimeMachine): stat: No such file or directory

Jul  6 12:33:32 Tower afpd[18537]: ipc_write: command: 2, pid: 18537, msglen: 24

Jul  6 12:33:32 Tower afpd[4397]: ipc_read: command: 2, pid: 18537, len: 24

Jul  6 12:33:32 Tower afpd[4397]: Setting clientid (len 16) for 18537, boottime 4C33055F

Jul  6 12:33:32 Tower afpd[4397]: Disconnecting old session 7241, client rebooted.

Jul  6 12:33:32 Tower afpd[4397]: ipc_get_session: len: 24, idlen 16, time 4c33055f

Jul  6 12:33:32 Tower afpd[18537]: afp_getsrvrparms(/mnt/disk1/_TimeMachine): stat: No such file or directory

Jul  6 12:33:39 Tower afpd[7241]: 37.80KB read, 106.44KB written

Jul  6 12:33:39 Tower afpd[7241]: Connection terminated

Jul  6 12:33:39 Tower afpd[4397]: server_child[1] 7241 done

 

I´m afraid that misinterpreted this discription:

 

You have to update your AppleVolumes.default and add tm  to your options, so it should something like this:

 

/mnt/cache/_TimeMachine "TimeMachine" allow:[user] cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

I guess that the path /mnt/cache/_TimeMachine is wrong? Should I put in the the name of the sparsebundle instead? Something like:

 

/mnt/disk1/edgars.sparsebundle "TimeMachine" allow:edgar cnidscheme:cdb options:upriv,usedots,tm perm:2770

Link to comment

I´m afraid that misinterpreted this discription:

 

You have to update your AppleVolumes.default and add tm  to your options, so it should something like this:

 

/mnt/cache/_TimeMachine "TimeMachine" allow:[user] cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

I guess that the path /mnt/cache/_TimeMachine is wrong? Should I put in the the name of the sparsebundle instead? Something like:

 

/mnt/disk1/edgars.sparsebundle "TimeMachine" allow:edgar cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

No, you should reference the folder, not the file. But the log says the folder

/mnt/disk1/_TimeMachine

does not exist, did you check this?

Link to comment

No, you should reference the folder, not the file. But the log says the folder
/mnt/disk1/_TimeMachine

does not exist, did you check this?

 

No I don´t have that folder. I do have all three sparsebundles for 3 users directly under /mnt/disk1/

 

Now, the error message makes sense, doesn't it ;)

 

I created a folder called _TimeMachine on my cache disk (no need to have this on the parity protected array). So I shared this folder through AFP, with the line you mentioned. If you want to share the root of disk1, you should share

/mnt/disk1

, but I wouldn't if I were you. Just create a subfolder on the disk and share that through AFP.

Link to comment

The issue might be, that the cache drive is only 250GB. The drives from the users to be backed up are 1TB, 320GB and lastly 120GB.

 

Additionally I forgot to mention that I have also difficulties to get access to the drives via AFP. In the past I was able to click on the Tower.AFP icon and it showed me the 3 drives immediately (...same as in the case of Tower.SMB). But this is not possible any more.

Link to comment

The issue might be, that the cache drive is only 250GB. The drives from the users to be backed up are 1TB, 320GB and lastly 120GB.

 

Additionally I forgot to mention that I have also difficulties to get access to the drives via AFP. In the past I was able to click on the Tower.AFP icon and it showed me the 3 drives immediately (...same as in the case of Tower.SMB). But this is not possible any more.

 

Well, you're not forced to use the cache drive, it's just faster... :)

 

If it's nothing working anymore, something probably changed. Did you check ownership and permissions?

 

Although I'm very aware of the fact that I was the one who created the tutorial, I should mention that I stopped using AFP altogether, because it was too much of a hassle with changing permissions and ownerships. I only use it for TimeMachine, but only rarely.

Link to comment

Yes you mentioned it in an earlier post - I don´t need AFP as well, except for Time Machine but this is key. Honestly it was one of the major objectives to centralize the backup and now I´m afraid that I took a wrong decision. A friend of mine is more happy with his TM backup on a NAS he recently bought.

 

Maybe we see a surprise with unRAID 5.0 ?

 

Thanks a lot dlmh - I will try a couple of things. My AppleVolumes.default:

/mnt/disk1 "disk1" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots perm:2770                                         

/mnt/disk2 "disk2" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots perm:2770                                         

/mnt/disk3 "disk3" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots perm:2770                                         

/mnt/disk1/_TimeMachine "TimeMachine" allow:user1,user2,user3 cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

Additionally I defined a user share /mnt/disk1/_TimeMachine but for the time being I do have access issues - not for disk1 but for the _TimeMachine folder.

 

{Update} I can access Tower.AFP in the Mac OSX Finder any more - which I could similarly to Tower.SMB. I check all of your descriptions and I´m afraid that this has something to do with my Time Machine issues (I also use AFP only for TM). Any advise? This is my only error message in the syslog:

 Jul 9 07:31:23 Tower sshd[7922]: error: Could not get shadow information for root

 

Link to comment
  • 5 months later...

Seems to be an issue with .AppleDB and .AppleDesktop within the respective share.

 

I've been using the Unraid 5 beta 2 with the Netatalk 2.05 package as a Timemachine backup.

It's been running for months without any major issues.

Made a user share "timemachine" and it spans three drives right now.

 

The drives being used are 1.5TB for parity and three 750GB for data (planning to start upgrading to 1.5TB drives soon)

 

There were problems when using AVAHI and DBUS. So all of that was left out when following the initial instructions in this topic.

Who needs to advertise where their backups are anyway? Security of the data is more important than speed or zeroconfig capabilities.

 

No Cache drive is being used either.

 

All the other information posted in this topic has been great and very helpful.

Here is some extra settings I've found to work while using UNRAID 5.0 Beta 2

 

Didn't have to copy the encrypted passwords to the Shadow file since 5.0 has that covered, but did have to confirm that /bin/false was changed to /bin/bash in the password and shadow files

 

The settings under your User Shares tab in the web interface:

 

Create a User Share called "Timemachine"

 

Click on the share to change some settings

 

CIFS

Export: "NO"

Security: "Secure"

 

User Access

YourUserNameHere: Read/Write

 

Go to Utilities tab in the web interface and start the permissions repair if their are any access issues.

 

my AppleVolumes.default file has this line at the end

 

Code:

/mnt/user/timemachine "timemachine" allow:YourUserNameHere cnidscheme:cdb options:upriv,usedots,tm perm:2770

 

minor problems I've had:

Can't seem to get ROOT user to work under AFP. Sucks, but isn't a big problem.

After booting up unraid, Timemachine fails to backup with an error message "..could not be accessed (error -1)" , but the second attempt and every attempt after that works fine.

 

Hope this helps all those impatient people waiting for Beta 3:)

Link to comment

Archived

This topic is now archived and is closed to further replies.


×
×
  • Create New...