CIFS permissions for the "root" /c share

[samtheman]

I had recently been confusing myself with file permission behaviour on an Ultra 6 that I use on a home network and that I use to share files across a few desktops/laptops.

I perform most of my operations using the admin account (probably not the best idea, hence some of the challenges I've hit).

On some of my shares "Read/Write" access option is enabled and also the  "Automatically set permissions on new files and folders" option is enabled.

I was concerned that some of the files being uploaded (by admin) had file permissions set to 755 i.e. no admin-users could edit/delete the file

-rwxr-xr-x  1 admin  admin       14729 2004-11-21 18:40 photo_invite5.jpg

Then I realised that my admin user was accessing the shares by going through the "root" \C share of the filesystem i.e. \\MyNAS\C is accessed

If I performed the same upload by accessing the \\MyNAS\media share (where media is one of the shares that has the appropriate CIFS permissions),then the behaviour was expected. Example file:

-rwxrwxrwx 1 admin admin 22425 2007-11-26 20:19 n514851355_169300_6156.jpg

How can I control the CIFS file permissions for the c/ share?

If I access the media share by going through c/media (i.e. through the c/ share), then the CIFS default file permissions for the media share are not respected. Is there anyway I can somehow enforce that the media share permissions apply even though, in effect that part of my filesystem is being accessed through the c/ share? 

[StephenB]

Interesting question...

I checked on my Pro, and found there was one share (Photos) that worked the way you wanted - the others didn't.

For some reason Photos had extended ACL set up (I have no idea why or how).

PRO:/c# cd /c
PRO:/c# getfacl Photos
# file: Photos
# owner: admin
# group: admin
user::rwx
user:admin:rwx
group::rwx
group:admin:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:admin:rwx
default:group::rwx
default:group:admin:rwx
default:mask::rwx
default:other::rwx

I created matching ACL on a test share, and then it also worked as you wish.

setfacl -Rm u:admin:rwx Test

setfacl -Rm g:admin:rwx Test

setfacl -Rm m::rwx Test

setfacl -Rm d:u::rwx Test

setfacl -Rm d:u:admin:rwx Test

setfacl -Rm d:g::rwx Test

setfacl -Rm d:g:admin:rwx Test

setfacl -Rm d:o::rwx Test

setfacl -Rm d:m::rwx Test

FWIW, you can remove the ACL with

setfacl -Rb Test

The emoticons above are : followed by o

I hadn't played with ACL before, and I am certainly not an expert on this.  So definitely try this yourself on a test share before you go with it.  There are some guides - here is one: http://bencane.com/2012/05/27/acl-using-access-control-lists-on-linux/

[mdgm-ntgr]

Accessing the c share is intended solely for administrative purposes not for regular adding of files.

[StephenB]

---

@mdgm wrote:
Accessing the c share is intended solely for administrative purposes not for regular adding of files.

---

Yes.  But though I know that's Netgear's intent I still do it from time to time (since it is very convenient to mount the whole volume as a drive letter).

However, I don't need the OP's desired behavior, so I don't intend to explore the setfacl approach further anytime soon.

FWIW, it doesn't change permissions on the c share itself.