Cannot find FreeNAS users/groups via windows share, and editing file causes read-only+owner change

[Rhombus12]

Hey, I've done a pretty thorough search of the forums here and have't seen anyone else encountering the problems I'm facing.

First, let me explain my setup:

I have two servers, one to work on and one to backup the files on the first server via rsync. For simplicity, however, I'll just be referring to the server I work off of even though the problem persists on both.

For about a year I've been using the server with multiple users/groups/datasets. I would always set the permissions in windows. I would connect to my share, and use properties>security to edit access to folders. However, recently after rebooting the server, when I try to edit permissions, it will ask me for someone with admin rights on the server to login with (even if I already am logged in as root), as such I will put in root credentials. Once doing so, when I then search a user or group that exists, it will tell me that it cannot be found at the server address. Therefore, I cannot edit user permissions anymore.

The above problem occurs whether dataset permissions are set to UNIX or Windows.

Another problem that occurs (probably linked to this) is that users become the owner of the files they edit. In doing so, the file becomes read-only to all other users, even if they are in the group that is supposed to have access to the file. It is possible to copy a file from the server using the CIFS share to the desktop, edit the file, and the copy it back to the server without permissions going haywire.

Trying to ignore windows permissions and only using UNIX permissions set in the webGUI does not fix the ownership problems.

All users can still login normally to the CIFS share. Their immediate ability to access the folders they should have access to (before anyone edits anything) also remains intact.

Let me know if anyone has encountered this problem before, or if they know what might be causing it. I know that the information I provided here about my setup is quite minimal, so let me know what particular information might be necessary and I will provide it.

Thanks.

 

[m0nkey_]

It sounds to me your permissions are not set correctly. See the video in my signature for a helpful how-to.

 

[Rhombus12]

Hi Monkey, I wish it were that simple. The thing is I cannot access my user or group list via windows explorer when trying to set permissions there. When I search for them, it says they do not exist. This is with the dataset's permissions being set to windows.

 

[Rhombus12]

This is what it looks like.

 

[anodos]

This is what it looks like. View attachment 12908 View attachment 12909

Setting permissions can be a bit of a "chicken and egg" problem. The user you're authenticated as needs to have permissions in order to set permissions. It doesn't look like you have them.

Post output of the following commands enclosed in [ code ] tags:

• Output of "smbstatus" when connected to \\<ip address>
• Output of "net usersidlist"
• Output of "net getlocalsid"
• Output of "net getdomainsid"
• Output of "pdbedit -L -v"
• Full output of "testparm" (you'll have to hit the 'enter' key to get it)

 

[Rhombus12]

Hi Anodos.

Here are the log files.

Although I don't know how to interpret these files, two things did appear to me. First, getdomainsid did not work. Second, pdbedit showed that the users are split between two domains.

 

[anodos]

Your users, groups, and servers appear to have the correct SID domain identifiers. Users appear to be authenticating and accessing data. The pdbedit output was a bit odd. Your testparm output didn't indicate your current workgroup, which is also odd. Post contents of following:

• /usr/local/etc/smb4.conf
• getfacl /mnt/Omega
• getfacl /mnt/Zanarkand
• recent / relevant entries in /var/log/messages, /var/log/samba4/log.smbd, /var/log/samba4/log.nmbd, /var/log/samba4/log.wb*

Out of curiousity, why aren't you using RFC1918 IP address ranges?

 

[Rhombus12]

Out of curiousity, why aren't you using RFC1918 IP address ranges?

The server is located on a university network. They use 129.49.

I'm not sure what to look for as relevant entries in those logs, but I did notice that

1. There are lots of "auth fail" in the messages log.
2. log.smbd is full of "connection failed" and "access denied"
3. log.nmbd is also littered with failed attempts of things

However, I would imagine that these logs occur when things don't work properly. As such, my interpretation of why these messages are occurring remains minimal.

 

[anodos]

The server is located on a university network. They use 129.49.

I'm not sure what to look for as relevant entries in those logs, but I did notice that

1. There are lots of "auth fail" in the messages log.
2. log.smbd is full of "connection failed" and "access denied"
3. log.nmbd is also littered with failed attempts of things

However, I would imagine that these logs occur when things don't work properly. As such, my interpretation of why these messages are occurring remains minimal.

Based on the below entry, it appears that your FreeNAS server's domain SID changed (possibly when you changed its hostname, more likely during some FreeNAS update). This means that Samba's mapping of Windows SIDs to Unix GIDs is broken.

Code:

[2016/07/28 13:27:22.175958,  0] ../source3/winbindd/winbindd_samr.c:769(sam_rids_to_names)
  sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2269952358-2403258015-2281837556

Well, it appears that your university has a large enough block of IPv4 addresses to deal them out to random computers on their networks. Cool, but not something you necessarily want for a samba server, and definitely something you want for your freenas server. As things currently stand, anyone on the internet can navigate to your FreeNAS web administrator page, make access your FreeNAS API, and of course, try to access the files on your server.

You need to firewall your FreeNAS appliance.

If I were in your place, I'd draw up a list of computers that need access to your FreeNAS server, create a secure network containing your FreeNAS server (i.e. firewall it off), then grant access to the server to the appropriate computers via something like OpenVPN.

There is a procedure (I'd have to look it up) to fix your group mappings, but based on the way the server is sitting publicly exposed, I think a fresh freenas install is probably in order (which will fix the group mapping issues).