[prev in list] [next in list] [prev in thread] [next in thread] 

List:       netatalk
Subject:    Re: [Netatalk-admins] Strange permission issues
From:       Josh Beard <josh () signalboxes ! net>
Date:       2011-11-22 18:31:19
Message-ID: 4ECBEA77.5070209 () signalboxes ! net
[Download RAW message or body]

To reply to my own post with more information:

I'm running into an issue where logging into a machine as an LDAP user 
and *mounting a share* as the user, I do not have permission to write to 
a directory that has the correct POSIX and ACLs set.  Mounting the same 
share as the same user on a machine that's logged into with a local 
account, I do have permission to write to the same location.

Still hoping for some insight, and I'm willing to volunteer this 
environment for testing :D

Thanks,
Josh

On 11/21/2011 09:01 AM, Josh Beard wrote:
> Greetings,
>
> I've recently implemented a Linux box with an EXT4 filesystem (with
> ACLs) and netatalk 2.2.1 to replace some of our temperamental Mac OS X
> servers.
>
> Unfortunately, I'm experiencing a number of bizarre permission issues.
> I have about 100 users that are using network homes via AFP here (via
> Open Directory) from predominately Mac OS X 10.6.8 clients.
> Additionally, I'm piloting netatalk with a shared folder where many
> users of the same group are dropping files and one person is
> administering it.
>
> For all of this, I've attempted to implement POSIX ACLs.  For the most
> part, the network homes are working fairly well.  However, I did come
> across one particular issue today - user tried to drag a file from their
> desktop into a directory on their desktop, but Finder gave the obscure
> error: "The operation can't be completed because an unexpected error
> occurred (error code -50)."  syslog on the server has something like:
>
> Nov 21 08:34:43 topeka afpd[17859]:
> ea_open('/media/store/homes/hs/students/studentsusername/Desktop/.AppleDouble/dployment.jpeg::EA'):
> bogus EA header file
> Nov 21 08:34:43 topeka afpd[17859]:
> ea_copyfile('/media/store/homes/hs/students/studentsusername/Desktop/dployment.jpeg'/'dployment.jpeg'):
> ea_open error:
> '/media/store/homes/hs/students/studentsusername/Desktop/dployment.jpeg'
>
> In the case of the shared folder, there are all kinds of oddities
> there.  For instance, users are unable to drop files into a directory
> there unless they put it inside a directory first and then copy the
> directory to the share.  This seems intermittent, and I typically don't
> see syslog entries related to this.
>
> The user that I've delegated "full control" over the shared folder to is
> also often unable to remove files that are dropped there, despite ACLs
> being set to allow it.
>
> Frequently, users that are members of a permitted group get Finder's "no
> access" symbol when trying to, for example, drag a file to a mounted
> share that they have write access to.
>
> Usually, these types of actions seem possible when performing them
> locally on the server (e.g. via an SSH session with a shell).
>
> I'm not terribly sure where to begin with pinning any of this down, or
> what kinds of "best practices" for permissions/ACLs might be.
>
> Once I get these types of quirks straightened out, I plan on
> implementing netatalk network-wide for around 2000 users.
>
> Any kind of insight is much appreciated!
>
>
> Here's what afpd -V reports:
>> afpd 2.2.1 - Apple Filing Protocol (AFP) daemon of Netatalk
>>
>> <snip>
>>
>> afpd has been compiled with support for these features:
>>
>>            AFP versions:    2.2 3.0 3.1 3.2 3.3
>> DDP(AppleTalk) Support:    No
>>           CNID backends:    cdb dbd last tdb
>>             SLP support:    No
>>        Zeroconf support:    Yes
>>    TCP wrappers support:    Yes
>>           Quota support:    Yes
>>     Admin group support:    Yes
>>      Valid shell checks:    Yes
>>        cracklib support:    Yes
>>          Dropbox kludge:    No
>>    Force volume uid/gid:    No
>>             ACL support:    Yes
>>              EA support:    ad | sys
>>            LDAP support:    Yes
> Here's the relevant entries in AppleVolumes.default:
>
> This share is where the mentioned shared directory is located (note:
> I've tried ea:sys as well with similar results):
>> /media/store/homes/hs/staff        "hs_staff"
>>   allow:@od_hsusers,@od_hsstudents,@od_itstaff options:usedots,upriv
>> ea:ad volcharset:UTF8
> This share is where the user's network homes are located (again, I've
> also used ea:sys here with similar weird results):
>> /media/store/homes/hs/students    "hs_students"
>>   allow:@od_hsusers,@od_hsstudents,@od_itstaff options:usedots,upriv ea:ad
> Here's the ACLs/Permissions for one of the folders in the share:
> # file: Review1/
> # owner: kclark  #<-- This user should have full access to anything
> being dropped here
> # group: od_kclark1  #<-- The users dropping to this share are members
> of this group (LDAP))
> user::rwx
> user:kclark:rwx
> group::rwx
> mask::rwx
> other::rwx
> default:user::rwx
> default:user:kclark:rwx
> default:group::rwx
> default:mask::rwx
> default:other::rwx
>
>


------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
Netatalk-admins mailing list
Netatalk-admins@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/netatalk-admins
[prev in list] [next in list] [prev in thread] [next in thread]