Download your favorite Linux distribution at LQ ISO.
Go Back > Forums > Linux Forums > Linux - Software
User Name
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.


  Search this Thread
Old 08-19-2016, 11:17 PM   #1
Registered: Oct 2007
Location: Italy
Distribution: Ubuntu
Posts: 82

Rep: Reputation: 17
Unhappy Folder group permissions weirdness

Hi there!

I have a samba linux server and a samba linux client.
The client mounts a "Recordings" share from the server in "/mnt/recordings".

Here is the mount definition from /etc/fstab:
//server/Recordings /mnt/recordings cifs rw,nouser,auto,credentials=/etc/samba/credentials,iocharset=utf8,soft,_netdev,comment=systemd.automount 0 0
and here is the related "mount" command output:
//server/Recordings on /mnt/recordings type cifs (rw,relatime,vers=1.0,cache=strict,username=bodom,domain=WORKGROUP,uid=0,noforceuid,gid=0,noforcegid,addr=,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=65536,actimeo=1,_netdev)
Now the problem is: I can't list the folder as "bodom" user. If I try to, I get a "permission denied" error.

Here are the permissions from "getfacl recordings":
# file: recordings
# owner: lightdm
# group: family
# flags: -s-
My user "bodom" is member of the "family" group (or at least "getent group" says so).
  • If login as root on the client, I can access the mounted folder.
  • If I change the permissions to "o+rx", I can access the mounted folder.
  • If I change the owner to "bodom", I can access the mounted folder.
  • If I use the "noperm" mount option, I can access the mounted folder.

So, in the end it looks like my system does not recognize "bodom" as being a member of "family".

Groups and users are inherited from the server via NIS.
I have this at the bottom of my /etc/passwd:
And this at the bottom of my /etc/group:
Could you help me hunt down this issue?
Old 08-21-2016, 10:23 AM   #2
Senior Member
Registered: Dec 2008
Location: root
Distribution: Slackware & BSD
Posts: 1,667

Rep: Reputation: 495Reputation: 495Reputation: 495Reputation: 495Reputation: 495
Have you tried create a local user bodom in the server?
Or change group ownership of client mount point to family, not gid=0.
Old 08-23-2016, 12:48 AM   #3
Registered: Oct 2007
Location: Italy
Distribution: Ubuntu
Posts: 82

Original Poster
Rep: Reputation: 17
Originally Posted by malekmustaq View Post
Have you tried create a local user bodom in the server?
Yes, the server has a local user "bodom"
Or change group ownership of client mount point to family, not gid=0.
I've just tried, but I am having same behavior
Old 01-13-2017, 06:04 AM   #4
Registered: Sep 2005
Posts: 32

Rep: Reputation: 0
It is a bug in the cifs.ko module, I think.

I do not understand why, but it checks the group permissions and then gets a negative.

I have written a patch against the cifs.ko kernel source for 4.4.0.x that introduces a "nogperm" option.

The only thing the option does is check if you are a member of the group, and then skip all other tests (which is only one, but still).

So if you are a member of the group you automatically get all permissions.

I... guess I wanted to say that I either didn't dig deep enough to find what was causing it, or this was the easier solution . But I didn't upload it yet.

The way I remember it the checking of the masks *should* function so that means the module gets the wrong information. However debugging a kernel module... I guess it requires writing to the kernel ring buffer (dmesg) and I haven't done that yet (this time). I just wanted a quick fix so I created a new option. The default of this option is "gperm" so by setting it to "nogperm" it just grants you automatic access.

If you are interested, I can upload it. It has an installation script that should work provided you are using 16.04 Ubuntu and using the latest default kernel. On the other hand it might still work in 16.10, but I haven't tested it.

The installation script will check whether you have the "linux-source" package installed, if not, it will install it. Then it unpacks the relevant part of the source archive in /usr/local/src, uses the supplied tool chain (in /lib/modules/$(uname -r or the latest source?)/build to build the module and leaves it sitting in /usr/local/lib/cifs.ko.

Then running it again with --install will just install it on top of the regular module, saving the existing one as a .bak file.

After a reboot the nogperm option works.

I forgot to say that the script also applies my patch, so it downloads the sources, unpacks the cifs module, applies the patch against the cifs module, and leaves it sitting in /usr/local/lib/cifs.ko. Then --install will copy it on top of the regular cifs.ko.

I just haven't had time or providence to actually create a package (using DKMS) out of it.

So after each kernel update you would have to reapply it. DKMS was the next step, but well, life got busy.

Summary: I have a patch + installation script available but I just need to upload it somewhere. Regards.
Old 01-13-2017, 06:20 AM   #5
Registered: Sep 2005
Posts: 32

Rep: Reputation: 0
Also, to add, this means the cifs.ko module actually does know about the proper group, and it knows about your groups.

That means the test to check whether you are a member of any of those groups, or rather, that the file in question has a group that you belong to, actually succeeds. The error is not in that.

It is the remaining part that fails. What happens is that the three parts of the mask are checked in turn to see if any yield a positive. Or something like it. This code is not part of cifs.ko, so there cannot really be a bug in it. This must mean that the mask supplied to/by the cifs.ko module must actually be faulty. The perms value for "group" must be faulty. The actual checking is done by a main filesystem component of the linux kernel.

So I would venture that there is a problem with the mask as it is derived or communicated to or by or inside of the cifs.ko module, because the weird part is that the stat() system call actually does see the correct permissions, right. So something is going wrong and I didn't debug it because copying the framework for another option was easier. In addition to that, the patch is only like 3 lines.

Two of which are parentheses ;-). So it is really a one-line patch + the infrastructure for adding another option.

Which was copy and paste, basically .

Regardless, you did find a bug I believe. I didn't write any bug report but was busy doing some writeup on my option and why it would be useful, but I think it got a tad long .


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Map/Mount Volume Group Folder to Volume Group Folder??? Led Zappa Linux - Newbie 4 09-21-2013 04:12 PM
Help setting group permissions on a folder ginda Linux - Security 3 01-18-2012 06:30 AM
Group Permissions with in a folder whc Linux - Server 1 05-30-2010 07:19 PM
group permissions in a folder rubella Linux - Newbie 5 01-18-2006 04:23 AM
group permissions based on folder perms grcunningham Linux - Networking 1 05-27-2005 04:50 AM > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 04:50 PM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration