CIFS Permissions Fouled Up (Again)

[ewhac]

I don't know exactly when this started, but my FreeNAS CIFS server is now showing all files with useless DOS permissions (rwxr-xr-x).

I think the problem is on the Linux side with the mount.cifs command. Something is injecting a bunch of unwanted garbage into the mount options. I try to mount the server like so (actually, I use the autofs mounter, but the result is the same):

Code:

sudo mount.cifs -o username=ewhac,uid=ewhac,gid=ewhac //theserver/ewhac /mnt

This succeeds, and the contents of /mnt is visible, but the `mount` command with no argument yields this entry:

Code:

//theserver/ewhac on /mnt type cifs (rw,relatime,vers=3.0,cache=strict,username=ewhac,domain=,uid=1000,forceuid,gid=1000,forcegid,addr=10.0.0.4,file_mode=0755,dir_mode=0755,nounix,serverino,mapposix,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

Obviously the nounix option has no business being there and, along with the file_mode and dir_mode options, is forcing the DOS permissions. Can anyone offer any suggestions where these unspecified options are coming from, and how I can bludgeon it back into submission? Is there possibly some server option I've set on the FreeNAS side that's causing mount.cifs to assume the server can't handle UNIX extensions?

 

[SweetAndLow]

Looks like the default options to me.

Might be helpful if you shared more information. Hardware specs, FreeNAS version, SMB setting, client is?

 

[ewhac]

Looks like the default options to me.

nounix is a default option?

Might be helpful if you shared more information. Hardware specs, FreeNAS version, SMB setting, client is?

Linux client system:

• Debian "Sid", kernel 4.13.4-1
  
• Intel i7-5820K, 16GiB RAM
  
• cifs-tools 2:6.7-1 ( smbclient --version prints "4.6.7-Debian")
• samba-common-bin: 2:4.6.7+dfsg-2

FreeNAS system:

• FreeNAS 11.0-U4
  
• HP N54L, AMD Turion II Neo dual-core @ 2GHz, 8GiB RAM, 2TBx3 RAIDZ1 + 250GB "scratch" drive

FreeNAS samba config:

• Use as home share: Enabled
• Apply default permissions: Enabled (dunno why this is set; I thought I cleared it)
• Export read-only: Disabled
• Browsable to Network Clients: Enabled
• Export Recycle Bin: Disabled
• Show Hidden Files: Disabled
• Allow Guest Access: Disabled
• Only Allow Guest Access: Disabled
• Hosts Allow: <blank>
• Hosts Deny: <blank>
• VFS Objects Selected: zfs_space, zfsacl, aio_pthread, streams_xattr
• Periodic Snapshot Task: unset
• Auxiliary Parmeters: <blank>

I can post my copy of /usr/local/etc/smb4.conf as well if you like.

 

[ewhac]

Necro!

Something happened last night that made me look at this again. I accessed the same share from my laptop, and the displayed permissions were correct. Mind you, my Linux laptop and desktop are configured identically, running the same versions of cifs-utils and dependent libraries. Yet the laptop was fine while the desktop was showing DOS-style rubbish.

The key difference appears to be in the `vers=` option. On the laptop, it comes up as `vers=1.0`, and UNIX extensions are enabled; on the desktop, it comes up with `vers=3.0` as above. On neither client platform am I explicitly setting this. On the server, I have the max protocol version set to 3.0.

I can't find any official documentation, or even well-established lore, to suggest that SMB 3.0 is incompatible with UNIX extensions. Can someone point me to additional reading on the subject?

 

[anodos]

Necro!

Something happened last night that made me look at this again. I accessed the same share from my laptop, and the displayed permissions were correct. Mind you, my Linux laptop and desktop are configured identically, running the same versions of cifs-utils and dependent libraries. Yet the laptop was fine while the desktop was showing DOS-style rubbish.

The key difference appears to be in the `vers=` option. On the laptop, it comes up as `vers=1.0`, and UNIX extensions are enabled; on the desktop, it comes up with `vers=3.0` as above. On neither client platform am I explicitly setting this. On the server, I have the max protocol version set to 3.0.

I can't find any official documentation, or even well-established lore, to suggest that SMB 3.0 is incompatible with UNIX extensions. Can someone point me to additional reading on the subject?

Unix extensions are SMB1 only. Lore established. for more info check out samba wiki + mailing list archives.

 

[ewhac]

Necro!

Some days ago, I learned about the multiuser option to mount.cifs. Basically, this option opens a new CIFS session for each local user accessing the share. So even though root may have mounted it, you can access it as yourself.

After a bunch of stumbling around, I ended up with this:

Code:

$ sudo mount.cifs -o "user=me,noperm,vers=3.0,multiuser,cifsacl" //myserver/labrat /mnt

Now, if you stop there, what you'll end up with is an inaccessible share, since it was mounted by root:

Code:

$ ls -al /mnt/me/tmp/
ls: cannot access '/mnt/me/tmp/': Permission denied

You need to do another step to automatically provide credentials to the CIFS server:

Code:

$ cifscreds add myserver
Password:

Enter your password for the share. Then look again:

Code:

$ ls -al /mnt/ewhac/tmp/
total 1291264
drwxr-xr-x 2 root root		 0 Jan  1 02:14  .
drwxr-xr-x 2 root root		 0 Jan  8 22:53  ..
-rw-r--r-- 1 root root   2939056 Feb 11  2016  invasion.mp3

And mount reports the following options in effect:

Code:

//myserver/labrat on /mnt type cifs (rw,relatime,vers=3.0,cache=strict,multiuser,domain=,uid=0,noforceuid,gid=0,noforcegid,addr=10.0.0.4,file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,cifsacl,noperm,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

This still isn't perfect; all the files appear to be owned by root (although I can freely create and delete files). This is because the server is sending the wacky Windows SIDs back to the Linux CIFS client, which causes an upcall to be made to a utility named cifs.idmap which translates between SIDs and Linux UIDs/GIDs. Unfortunately, it needs winbind to work, which in turn needs other stuff to work, and that's when I stopped following the rabbit hole.

Still, the permissions appear correct, which is a lot farther than I've gotten before on this path.

 

[ewhac]

Necro! So, here's what I've settled on for the automount map:

Code:

freenas   -fstype=cifs,vers=3.0,username=${USER},uid=${USER},gid=${USER},cifsacl,credentials=/etc/auto.master.d/credentials/${USER}  \
	 /${USER}	  ://freenas/${USER}

This results in the following entry in the Linux mtab when mounted:

Code:

//freenas/me on /cifs/freenas/me type cifs (rw,relatime,vers=3.0,cache=strict,username=me,domain=[[workgroup]],uid=1000,forceuid,gid=1000,forcegid,addr=[[x.x.x.x]],file_mode=0755,dir_mode=0755,soft,nounix,serverino,mapposix,cifsacl,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)

The UID/GID displays correctly on the client side (but then it would, because it's being forced), and the file permissions seen on the client match those on the server. getcifsacl even appears to work correctly. I've even stopped getting the "can't preserve all permissions" warning I got from mv when moving files to the share.

Now to figure out what these messages are all about, and how to make them go away:

Code:

Apr 28 00:01:25 exiguous cifs.idmap[4106]: key description: cifs.idmap;0;0;39010000;os:S-1-5-21-1373117891-486326805-1839722007-3000
Apr 28 00:01:25 exiguous cifs.idmap[4106]: Unable to convert cifs.idmap;0;0;39010000;os:S-1-5-21-1373117891-486326805-1839722007-3000 to UID: Some IDs could not be mapped.
Apr 28 00:01:25 exiguous cifs.idmap[4107]: key description: cifs.idmap;0;0;39010000;gs:S-1-5-21-135190865-3541278195-1833594169-1000
Apr 28 00:01:25 exiguous cifs.idmap[4107]: Unable to convert cifs.idmap;0;0;39010000;gs:S-1-5-21-135190865-3541278195-1833594169-1000 to GID: Some IDs could not be mapped.