SMB/CIFS mount on Linux problem when creating file/folder

[hmeij]

So I'm not getting much traction with NFS4 unix storage datasets and shares. Not sure why, so I'm trying to get the linux CIFS mount working instead.

On dataset/share type windows, all permissions are working as expected when mapping to a Windows desktop. Owner/Group is applied with default permissions, recursive.

From windows desktop connected to AD (same domain as FreeNAS), create folder/file ( ls -l, ls -ln output)
Dataset is owned by this user/group

Code:

drwxrwxr-x+ 2 WESLEYAN\hmeij  WESLEYAN\hmeijgroup  2 Feb 20 09:32 win1
-rwxrwxr-x+ 1 WESLEYAN\hmeij  WESLEYAN\hmeijgroup  0 Feb 20 09:32 win1.txt
drwxrwxr-x+ 2 24307  193064  2 Feb 20 09:32 win1
-rwxrwxr-x+ 1 24307  193064  0 Feb 20 09:32 win1.txt

Now different user logs into linux server connected to same AD using nscd/nslcd+kerberos
New use is part of hmeijgroup, after login and file creation
Next mount that share and create folder/file, for now do it as root

Code:

# for now as root on behalf of user
[root@rstoresrv3 ~]# mount -t cifs //whitetail/testwin1 /mnt -o username=WESLEYAN\\\hmeij,domain=wesleyan
Password:

[root@rstoresrv3 ~]# mount | grep whitetail
//whitetail/testwin1 on /mnt type cifs (rw)

# login user
[hpc100@rstoresrv3 ~]$ id
uid=75000(hpc100) gid=75000(hpc100) groups=75000(hpc100),11417(hmeijgroup)

[hpc100@rstoresrv3 ~]$ mkdir /mnt/win2
mkdir: cannot create directory `/mnt/win2': Permission denied
[hpc100@rstoresrv3 ~]$ touch /mnt/win2.txt
touch: cannot touch `/mnt/win2.txt': Permission denied

[hpc100@rstoresrv3 ~]$ ls -l /mnt
total 1
drwxrwxr-x 2 24307 193064 0 Feb 20 10:02 win1
-rwxrwxr-x 1 24307 193064 0 Feb 20 10:02 win1.txt
-rwxrwxr-x 1 24307 193064 0 Feb 20 10:05 win2.txt
[hpc100@rstoresrv3 ~]$ ls -ld /mnt
drwxrwxr-x 4 24307 193064 0 Feb 20 10:05 /mnt

What a weird behavior. Permission denied errors but the file creation succeeds the directory not. Noteworthy to state that if log in as different user in windows and map the drive the file and folder created are owned by hpc100 but have group is hmeijgroup. So not exactly same behavior. Ideas?

-Henk

 

[Nick2253]

Is it possible that hpc100 hasn't logged out/logged back in since adding it to the hmeijgroup?

 

[hmeij]

No hpc100 has been there all this time during testing.
Some progress, on linux server connected to AD using smbclient

Code:

[hmeij@rstoresrv3 ~]$ smbclient -U hpc100 -W WESLEYAN //whitetail/testwin1
Enter hpc100's password:
Domain=[WESLEYAN] OS=[Windows 6.1] Server=[Samba 4.7.0]

smb: \> mkdir linux2
smb: \> put /tmp/auto_1.log linux_2.log
putting file /tmp/auto_1.log as \linux_2.log (177.5 kb/s) (average 177.5 kb/s)

And on FreeNAS server we observe

Code:

root@whitetail:/var/log # ls -l /mnt/Vol01/testwin1/linux*
-rwxrwxr-x+ 1 WESLEYAN\hpc100  WESLEYAN\hmeijgroup  1272 Feb 20 14:32 /mnt/Vol01/testwin1/linux_2.log
drwxrwxr-x+ 2 WESLEYAN\hpc100  WESLEYAN\hmeijgroup	 2 Feb 20 14:30 /mnt/Vol01/testwin1/linux2

That works as intended. I'll dig around some more but this is actually a better solution as we do not have to fuss with NFS mounts. Macs tested OK so I think I'll go with SMB/CIFS across all platforms. If I need to I can provide NFS read only mounts for data retrievals in my HPC environment.

One semi off topic Q: When testing a windows type dataset owned by nobody:nobody with no recursive permissions I can add individual users in the windows share with Aux line: valid users = WESLEYAN\hmeij, WESLEYAN\hpc100 (in this case I make the user's folders on freeNAS file system and set permissions to drwx------, iow owner only use case scenario).

That works but the Aux line: valid users = WESLEYAN\hmeijgroup does not (permission denied). Should groups work, need special +@? prefix for AD groups?

-Henk

 

[Nick2253]

I believe that groups need to be preceded by an @ in the valid users parameter.

 

[hmeij]

The @ symbol is used to refer to groups in /etc/groups ... just tested that out and it did not fix this issue.

However, the fact that the smb tools work and the NFS mount -t cifs does not pointed me to

Code:

root@whitetail:/var/log # grep idmap /usr/local/etc/smb4.conf
	idmap config *: backend = tdb
	idmap config *: range = 90000001-100000000
	idmap config WESLEYAN: backend = rid
	idmap config WESLEYAN: range = 20000-90000000

rid? why did freenas not choose ad? So that means the users's uid/gid come from freenas with smb tools but from ad when performing a mount. Might also explain why I'm getting nowhere with NFS mounts.

Need to read up on how to change rid to ad ....editing smb4.conf will probably not survive a reboot.

 

[Nick2253]

I would suggest filing a bug report on this. That will get it on the radar of the developers, and even if there's a good reason they picked rid in the first place, they can at least make a dropdown if it's a parameter that needs changing.

If you do file a bug report, please post the link back here.

 

[hmeij]

Hey Nick, I found it

Directory>Active Dir>IDMap Backend>pull down select "ad"
WinBind NSS INfo >pull down RFC2037

This requires the unix uid/gid values to be filled out in AD. I guess I was not looking at this because the option "Unix Extensions" led me to believe it was taken care of, deh.

Blowing my test environment away and restarting. Will update thread.

-Henk

 

[hmeij]

Well, idmap ad and nss rfc2307 yields getpwnam and getgrnam errors for each object referring to objects like 'WESLEYAN\\hmeij' which incorrect, should be one \ in object or \\\ when using a shell. Seems to be a problem previously encountered.

So I tried idmap ldap and provided bind info for bind there (edit button). Now looksie

Code:

root@whitetail:/var/log # wbinfo -u | wc -l
   56664
root@whitetail:/var/log # wbinfo --user-info WESLEYAN\\\hmeij
WESLEYAN\hmeij:*:8216:90000005::/home/WESLEYAN/hmeij:/bin/sh
root@whitetail:/var/log # wbinfo -g  | wc -l
   16946
root@whitetail:/var/log # wbinfo --group-info WESLEYAN\\\hmeijgroup
WESLEYAN\hmeijgroup:x:11417:

Those are the correct uid/gid from AD. Yea.

 

[hmeij]

What now? When I try changing permissions on a dataset the "loading permissions" spins forever (15 mins+) and never finishes. Reboot. Same behavior, have to terminate the uwsgi process to get my server back. This app appears to have trouble with our wacky AD environment I'm thinking or there wouldn't be any 9M downloads.

Back to idmap rid and assess if we can live with it. Client access (mac,win,linux) would be ok but I need to provide these shares as NSF mounts in private HPC network. Maybe read only mounts might work.

-Henk

 

[hmeij]

Well, bizarre. Rebuild my test environment with idmap set to rid and winbind NSS to nothing. And suddenly it picks up AD uid/gid correctly! Did an update and reboot and the uid/gid still come from AD. Now I tested an SMB/CIFS share on windows/mac clients, then mounted that share as an NFS mount on a linux server. It all works as expected. But I don't know what's going on under the hood or how one would expect a production deploy to work the same way.

-Henk

Code:

root@whitetail:/var/log # ll /mnt/Vol01/testwin1
total 4
-rwxrwxr-x+ 1 WESLEYAN\hmeij   WESLEYAN\hmeijgroup  0 Feb 22 13:57 .windows*
-rwxrwxr-x+ 1 WESLEYAN\hmeij   WESLEYAN\hmeijgroup  0 Feb 22 14:13 foo*   <--- linux
drwxrwxr-x+ 2 WESLEYAN\hmeij   WESLEYAN\hmeijgroup  2 Feb 22 14:13 foodir/
drwxrwxr-x+ 2 WESLEYAN\hmeij   WESLEYAN\hmeijgroup  2 Feb 22 14:00 New folder/ <--- win
drwxrwxr-x+ 2 WESLEYAN\hpc100  WESLEYAN\hmeijgroup  2 Feb 22 14:03 folder/  <--- mac
-rwxrwxr-x+ 1 WESLEYAN\hpc100  WESLEYAN\hmeijgroup  0 Feb 22 14:03 Text.txt*
-rwxrwxr-x+ 1 WESLEYAN\hmeij   WESLEYAN\hmeijgroup  0 Feb 22 14:00 New Text Document.txt*
root@whitetail:/var/log # ll -n /mnt/Vol01/testwin1
total 4
-rwxrwxr-x+ 1 8216   11417  0 Feb 22 13:57 .windows*
-rwxrwxr-x+ 1 8216   11417  0 Feb 22 14:13 foo*
drwxrwxr-x+ 2 8216   11417  2 Feb 22 14:13 foodir/
drwxrwxr-x+ 2 8216   11417  2 Feb 22 14:00 New folder/
drwxrwxr-x+ 2 75000  11417  2 Feb 22 14:03 folder/
-rwxrwxr-x+ 1 75000  11417  0 Feb 22 14:03 Text.txt*
-rwxrwxr-x+ 1 8216   11417  0 Feb 22 14:00 New Text Document.txt*