[RESOLVED] netatalk 0.4.3 ongoing issues

We still have a problem. If Allow Guest (allow:nobody) is set for a share, then an authenticated user cannot see said share. Also, for some reason at least one of the shares have to have that option turned on so that the other shares are visible for guests. No special modifications, other than having to manually add "deny:nobody" to my Time Machine share in order for the guest account to actually work on the public and media shares:

"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/TimeMachine/" "TimeMachine" options:upriv,usedots,invisibledots,tm deny:nobody
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Media/" "Media" options:upriv,usedots,invisibledots,mswindows
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Public/" "Public" options:upriv,usedots,invisibledots,mswindows allow:nobody rwlist:nobody
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Private/" "Private" options:upriv,usedots,invisibledots,mswindows deny:nobody

Is driving me crazy, nothing changed before the updates. The plugin is 0.4.3.

*Update: Setting the shared folder privileges for Public in the login group (administrators in this case) allows Public to be shared now for the authenticated user. This is just a work around

"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/TimeMachine/" "TimeMachine" options:upriv,usedots,invisibledots,tm deny:nobody
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Media/" "Media" options:upriv,usedots,invisibledots,mswindows
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Public/" "Public" options:upriv,usedots,invisibledots,mswindows allow:nobody,@administrators rwlist:nobody,@administrators
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Private/" "Private" options:upriv,usedots,invisibledots,mswindows deny:nobody

So after some testing, this is what I found out: If at least one share doesn't have the Allow Guest option turned on, then afpd.conf will not contain the uams_guest.so option. Volker: I would recommend that in order for this to work properly with guest accounts, the guest account should be an option on the main settings page or make it a permanent enabled option. Then per share, a drop-down list with a combination of the things that guest can or cannot do:

Zitat

Guest Login: Denied- Will add "deny:nobody" to the share
Guest Login: Allowed, read-only- Will add "allow:nobody,@users rolist:nobody" to the share
Guest Login: Allowed, read/write- Will add "allow:nobody,@users rwlist:nobody" to the share

I think this is a simpler method and I am sure it will work much better. I already tested it with these options and seems to work perfectly. Thoughts?

Well that's okay, as long as 'allow:nobody,@users' is added when enabling guest access to each share like I explained above, and an option to deny guest is also helpful for those of us that wants to keep some shares hidden away from guests. This is all a fix for authenticated users access those public shares, I do remember having a similar issue with FreeNAS and the fix was the same.

To answer your question, adding 'allow:nobody,@users' will yield the intended result because the original idea is to make it a public share. And yes, OSX automatically assumes the guest account when no credentials are in use, or when the current user name is invalid. A valid user name with the wrong password will yield a failed authentication error, but both scenarios gives a choice to the user with a "Connect As..." button:

Adding uams_guest.so to the /etc/netatalk/afpd.conf file will make visible every share to 'nobody'. Now, if you want to be more granular on what you want 'nobody' to have access to, you use the parameters 'allow:nobody' and 'deny:nobody' per share.

The side effect of using 'allow:nobody' is that only the guest account can see that said share. If you authenticate with something other than nobody, that very same share will disappear and will no longer be available. Combining it with @users will solve the issue with OMV since every registered user belongs to this group. This can be combined with file level permissions by using ACL in case there is something you want to restrict within that share.

To make shares invisible to 'nobody' and deny access, 'deny:nobody' is used. I do this for my private and time machine shares.

I don't know if this is an OSX or a Netatalk behavior, but this is something I have seen in the past with FreeNAS as I mentioned before and does not appear to be a bug. It was easier to get around the issue back then because there was a field per share for 'allow' and another one for 'deny', so all I had to do was fill in the users and/or groups to my content.

Yes this is confusing. All I know is that as long as /etc/netatalk/afpd.conf is configured with 'uams_guest.so', every share will be visible for the guest user unless the share has 'deny:nobody' in it. If you add 'allow:nobody' then only the guest user can look at the share making it exclusive to that user only, overriding everything else.

The OS itself is smart enough to attempt the guest login automatically if the current user credentials in the OS fail authentication. If guest is allowed, it shows the shares. If guest is not allowed, it simply doesn't show any resources. In both cases, you still can press the "Connect As..." button and go from guest to an authenticated user.

So to make it simpler, I think the BEST way to make this work without any complicated options, is to simply have 'uams_guest.so' permanently enabled, and have deny:guest for every created share as default. If the user checks the mark for 'Allow guest login', then that option will be removed from the share config and 'allow:nobody' will NOT be necessary. This in turn will also work with authenticated users, rendering my previous solution obsolete. Here's the best config for shares I was able to come up with:

"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/TimeMachine/" "TimeMachine" options:upriv,usedots,invisibledots,tm deny:nobody
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Media/" "Media" options:upriv,usedots,invisibledots,mswindows
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Public/" "Public" options:upriv,usedots,invisibledots,mswindows
"/media/77dcf10f-c991-45b1-b903-b57abf0c6f1a/home/Private/" "Private" options:upriv,usedots,invisibledots,mswindows deny:nobody

This works 100%, and authenticated users can now see the public shares. Permissions such as read-only are configured through ACL, so I don't see the need for a read-only option per share.

Let me add to that: If a read-only option on a share is needed for the guest user in combination with a public share, I would have it insert 'rolist:nobody' to the share config. Or if the whole share has to be read-only for every user, 'rolist:@users' would work just like SMB in that case, preventing everyone from writing.

Issue is resolved with AFP 0.4.6