MacOS – Why is permission denied on this folder

filesystemmacospermission

I'm trying to understand why I do not have access to a sub-folder in my "Downloads" folder. The folder in question has the following rights:

drw-r--r--   29 laurent  staff   986B Feb 20 14:06 Example

and whoami gives 'laurent'. So as I understand, anybody can view this folder and I am the owner.

However, when I do cd Example, I'm getting:

bash: cd: Example/: Permission denied

In fact it seems to be true of all the sub-folders in my "Downloads" folder, none of them can be accessed (without using sudo). Any idea what could be the reason?

Best Answer

To be able to list or enter a directory you need execute permission

e.g

drwxr-xr-x   2 mark  staff      68 18 Mar 14:00 example

Use chmod to change the permissions, also check the setting of umask to see the default

Related Solutions

MacOS – Changing read permissions on /private/etc recursively

Changing the permissions on /private/etc/sudoers is definitely a no-no. The sudo command will fail to work if that file's permissions are not 0440 as you are noticing. This is a security measure -- the command distrusts any permission setting that is less restrictive than 0440 as it allows for potential tampering with sudo permissions on the box.

Normally you'd boot in to single user mode to fix this problem. This lets you log in with elevated privledges so you can do a:

chmod 440 /private/etc/sudoers

and get your sudo command back.

But I found this article that had an alternative that doesn't require a reboot and works if your account has Administrator level access. I haven't tried it, but it seems sound.

Open a Finder window a hit Shift-Command-G to get the "Go To" dialog. Enter /private/etc in the dialog and hit the Go button.

Find the sudoers file in the Finder window, select it and press Command-I to open the information window for the file and change the permissions on the file so they match:

Permissions for your sudoers file

Close the information window and you should be back in business.

All this being said: I would strongly encourage you to rethink changing the permissions of everything under /private/etc to be world readable. This poses a serious security risk (as seen from the way sudo locks you out when you make /private/etc/sudoers world readable) to your machine. Maybe there's another Ask Different question here that'll help you solve a problem you think you're solving by making these unsafe changes?

Samba share randomly unable to move files/folders

After a bit of research I've come up with a workable solution - at least I'm not changing it for the time being.
Check 'ignore ownership' is unticked on the external volume where the share resides.

Change the users primary group id from 'staff' to custom group id

sudo dscl . -change /Users/lmessi PrimaryGroupID 20 567

Remove all ACLs from External drive 'Disk1'

chmod -RN /Volumes/Disk1

[if you get any errors, try recursive unlock files beforehand]

sudo chflags -R nouchg /Volumes/Disk1

change group ownership recursively for the group 'design'

sudo chgrp -R design /Volumes/Disk1

You can check ownership with ls -gl

ls -gl /Volumes/Disk1

Then my smb.conf file looks something like this

[global]
    socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
    unix extensions = no

        guest ok = No
        read only = No
        force group = design

    create mask = 664
        force create mode = 664
        security mask = 664
        force security mode = 664
        directory mask = 2775
        force directory mode = 2775
        directory security mask = 2775
        force directory security mode = 2775

[Share1]
        comment = Share1
    path = /Volumes/Disk1/Share1
        valid users = mickey, donald
        admin users = mickey, donald

Best Answer

Related Solutions

MacOS – Changing read permissions on /private/etc recursively

Samba share randomly unable to move files/folders

Related Question