AFP Permission issues after new FW update

mdgm wrote:
Change the default access permissions for AFP for the share, apply. Uncheck the box to allow guest access, apply. Revert default access permissions for the share (e.g. to disabled) and click Apply. I did this earlier today and it worked for me.

mdgm,

Thanks for this tip. I will have to try it later today.

Strange issues here too- Duo on latest beta.

If i made a few new folders via the finder, and place some media in them, my WDTV can't see the media. It sees the folder, just no media. If i move the video to a previously existing folder, the video shows and plays fine. Very odd.

Thanks
Dan

sirozha wrote:
So, is this a standard mechanism of providing guest access in various Linux flavors or is this something that the RedyNAS team implemented?

The "nobody" user and "nogroup" group are standard Linux features (UID = GID = 65534). Mapping the OSX "guest" user to the linux "nobody" user is the default setup implemented by netatalk - so yes you can consider this "standard"

sirozha wrote:
According to that Wikipedia article, the stick bit - when set on a directory in Linuxv- restricts the renaming and unlinking of the files in that directory unless this is done by the root or owner. Is "unlinking" the same thing as "deleting"?

I would interpret it that way, though I've never really noticed the use of "unlink" in that article before. Here's the linux man page description which is perhaps a better description:

Linux man pages wrote:

A directory whose `sticky bit' is set becomes an append-only directory, or, more accurately, a directory in which the deletion of files is restricted. A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory and the user is the owner of the file, the owner of the directory, or the super-user. This feature is usefully applied to directories such as /tmp which must be publicly writable but should deny users the license to arbitrarily delete or rename each others' files.

sirozha wrote:
In Mac OS X, there is a requirement that the owner of the file must has the write permission to the file in order to be able to delete it when the sticky bit is set on the enclosing directory. Is there such a requirement in Linux as well?

Depends - as the man page states: "A file in a sticky directory may only be removed or renamed by a user if the user has write permission for the directory..."

In that case, if the *file* does not have write access permission then it may still be deleted - the user is typically prompted to over-ride the lack of write permission, but that option may then be application dependent.

mdgm wrote:
Change the default access permissions for AFP for the share, apply. Uncheck the box to allow guest access, apply. Revert default access permissions for the share (e.g. to disabled) and click Apply. I did this earlier today and it worked for me.

Unfortunately I couldn't do this because I was unable to mount the default share of user (eg user XYZ automatically has a default share named XYZ which is only available to user and admin).

This is a default share (like media) but unlike media you're not able to change anything for obvious reasons.

However, simply restarting my mac solved the problem??? I'm a noob of course, but as Time Machine was working, the media share etc. was working fine, I just couln't figure why the default user share should be so obstinate.

I hate to cross-post, but maybe my issue is related to this one?

In my attempt to auto-mount my AFP shares after reboot, I ran across this problem with my NV. My shares do not display any info. I'm using Lion, and 4.1.8.t5.

I can access the shares from Lion, no problem. When I try to select Get info, I get this:



When I used Command +K, I'm able to connect via afp://xxx.xxx.x.xxx and can see my shares on the NAS NV. However, they are grayed out, I cannot select them.

So, something is wrong, but I don't know if it's an NV setting, or a Lion issue.