FreeNAS-11.1-U3

[InQuize]

Generate a debug file and send it to me by private message.

I'd rather not give away any information about my production system; gave a quick look at that debug content and I'd rather not.. On the other hand I'm willing to setup another system to reproduce any issues and generate it there if needed.
And it's not that broke anyway, I reverted changes in SMB aux parameters and it works normal again.

 

[g3rt]

I believe @KrisBee 's answer from one of the other threads are correct: The upgrade wipes sambas password database.
I have tried the following that works:
A: Manually add users back to samba password db using "pdbedit -a -u <username>" where username matches existing FreeNAS user name. Then logging in with existing username and password works. This is a pretty scriptable solution for those with a lot of users having stumbled into the problem already, and doesn't require a password change for users. Could perhaps be included in an update script, even. BUT: I have no idea if this ties in with the FreeNAS way of handling user details, and if it would cause problems down the way, as I have really no idea how FreeNAS handles users between services.
B: Creating new users in the FreeNAS control panel. New users gets added to the samba pw database. Stop gap measure, but works.
C: changing passwords for users in the FreeNAS control panel. NOTE I'm not 100% sure this works, as I can't swear on my life that it was a user I hadn't already added back using pdbedit.

 

[ka5zci]

Well....add me to the legions of other whose users can no longer access their shares. I am currently trying to revert to the previous 11.1-U2. System comes back after Reboot still as U3. As an aside, I am NOT able to change a couple of the password for existing shares (built back in the version 9 days) with an error stating "Volume root directories cannot be used as user home directories." This has been ever since upgrading to 11.1 directly from 9.10.2-U6 where everything worked without errors and no complaints from the system regarding Voume root directories...Can I revert all the way back to 9.10 safely? If not, I am lost how to resolve.

 

[dlavigne]

Can someone confirm whether or not this workaround resolves it:

Code:

rm -Rf /var/db/samba4/.usersimported
/usr/local/libexec/nas/generate_smb4_conf.py
service samba_server restart

 

[InQuize]

Same output as from: service ix-pre-samba restart part of it?
Same outcome. Permission denied.

Code:

[root@NAS ~]# /usr/local/libexec/nas/generate_smb4_conf.py																		
Importing account for A...ok																								
Importing account for B...ok																								 
Importing account for C...ok																									
...																									
Enabled user A.																											 
Failed to disable B																											
Failed to disable C																											 
...																										 
Granted SeTakeOwnershipPrivilege to NAS\A																					
Granted SeBackupPrivilege to NAS\A																							
Granted SeRestorePrivilege to NAS\A

Notice: user A is the only one that I updated with the same password via GUI.

 

[FlangeMonkey]

I've found something, but I don't think it will be persistent.

there is an extra line in /usr/local/etc/smb4.conf

Code:

private dir = /root/samba/private

I have removed this line, restarted samba and it has resolved it for me.

 

[ka5zci]

Can someone confirm whether or not this workaround resolves it:

Code:

rm -Rf /var/db/samba4/.usersimported
/usr/local/libexec/nas/generate_smb4_conf.py
service samba_server restart

Did not work for me...FYI samba4 folder on my machine is named (samba4.20180320180104), contains one Folder "Private" and it is empty. Workaround ran with failures on every user saying "Failed to Disable".

 

[anodos]

I've found something, but I don't think it will be persistent.

there is an extra line in /usr/local/etc/smb4.conf

Code:

private dir = /root/samba/private

I have removed this line, restarted samba and it has resolved it for me.

This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

 

[FlangeMonkey]

This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

That line is not present in my RELEASE build, should it even be there?

 

[MrToddsFriends]

This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

On my system this line was automatically added to the Samba config during the U3 update without applying any aux parameters, as I already pointed out much earlier in this thread
https://forums.freenas.org/index.php?threads/freenas-11-1-u3.62500/#post-445988
Is this the culprit?

 

[FlangeMonkey]

On my system this line was automatically added to the Samba config during the U3 update without applying any aux parameters, as I already pointed out much earlier in this thread
https://forums.freenas.org/index.php?threads/freenas-11-1-u3.62500/#post-445988
Is this the culprit?

by my test, I would say yes.

 

[BaT]

Did not work for me...FYI samba4 folder on my machine is named (samba4.20180320180104), contains one Folder "Private" and it is empty. Workaround ran with failures on every user saying "Failed to Disable"

That's different folder. /var/db/samba4/ normally a symlink to the system's dataset /var/db/system/samba4. You can check there for the files.

 

[dlavigne]

One more suggested workaround, if someone could test please and confirm:

mkdir -p /root/samba && cp -Rp /var/db/samba4/private/ /root/samba/private/

 

[ka5zci]

That's different folder. /var/db/samba4/ normally a symlink to the system's dataset /var/db/system/samba4. You can check there for the files.

Sorry...I should have copied the full instruction for what I was reporting on...
Requested by DL... and I gave feedback.


Can someone confirm whether or not this workaround resolves it:

Code:

rm -Rf /var/db/samba4/.usersimported
/usr/local/libexec/nas/generate_smb4_conf.py
service samba_server restart

Appreciate your followup though!!! Thanks

 

[kdbaumann]

Ok I have the following interesting bit of data. I upgraded all my servers. The ones talking to Veeam no longer work and rolling back has done nothing to help. Resetting passwords on both U2 and U3 have had zero impact. I am dead in the water.

Further I have a very old SMB server that I have been using the following code in forever... Like way back to Samba days pre FreeNAS.

Code:

[FreeHome]
	comment = Home directory
	path = /mnt/zVol01/%U
	public = no
	writable = yes
	valid users = kdb dhemmert source mebsaddle dario marta
	nt acl support = yes
	force group = wheel
	create mask = 0700
	directory mask = 0700

What this does is create a "home" directory for those user's listed in /mnt/zVol01/kdb for example. This all worked fine.

Now regardless of rolling back or whatever the "home" directory no longer works. But changing the password on kdb made all of my other shares work just fine. Just not this one.

Thoughts on either the Veeam issue or this one? I get a dialog in Win10 stating:

Windows cannot access \\FREENAS\FreeHome\ You do not have permission to access \\FREENAS\FreeHome\/ Contact your network administrator to request access.

Most important is getting customers Veeams backups running... But my personal server which worked up until I moved from U2 to U3 would be lovely as well. I did roll back and reset passwords in both versions... NADA.

EDIT: fixed this issue by changing all of the "home" directories (/mnt/zVol01/kdb) permissions to 777... This is not really a solution but gets the users where they need to go for now.

Veeam still will NOT connect to any of the old servers (regardless of version at this point) at all.

 

[BaT]

Ok I have the following interesting bit of data. I upgraded all my servers. The ones talking to Veeam no longer work and rolling back has done nothing to help. Resetting passwords on both U2 and U3 have had zero impact. I am dead in the water.

Veeam still will NOT connect to any of the old servers at all.

Can you try with the U3 one of the suggestions:

1. This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

Or, which would have the same effect ATM:

2. mkdir -p /root/samba && cp -Rp /var/db/samba4/private/ /root/samba/private/

Both approaches address the same issue - in the generated smb4.conf there is now a setting private dir = /root/samba/private/ that points to the directory where user passwords and other sensitive information is stored. In the past and by default that directory used to be /var/db/samba4/private/.

So, first approach rewrites location of the private dir to the previous place, while second copies all the essential files to the new location.

First approach may be better as in the fix to this issue the location of the private dir is going to be placed back to /var/db/samba4/

 

[xviruz]

Can you try with the U3 one of the suggestions:

1. This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

Or, which would have the same effect ATM:

2. mkdir -p /root/samba && cp -Rp /var/db/samba4/private/ /root/samba/private/

Both approaches address the same issue - in the generated smb4.conf there is now a setting private dir = /root/samba/private/ that points to the directory where user passwords and other sensitive information is stored. In the past and by default that directory used to be /var/db/samba4/private/.

So, first approach rewrites location of the private dir to the previous place, while second copies all the essential files to the new location.

First approach maybe better as in the fix to this issue the location of the private dir is going to be placed back to /var/db/samba4/

The first approach fixed write permissions on all my users (those that have writes can write). I deleted the aux parameter afterwards and restarted the SMB service and the write permissions remain working...

 

[SoggyF]

Rolling back worked for the most part. But I did have a lingering issue in my open share folder. It still didn't give full permissions. Was able to access but cold not move/delete/create files. So I just deleted the SMB shares and recreated again from the gui which seems to have fixed it.

 

[MrToddsFriends]

Can you try with the U3 one of the suggestions:

1. This can be made permanent by setting private dir = /var/db/samba4/private as an auxiliary parameter under Services->SMB

SMB shares work as usual after adding this aux parameter on my system. On client side shares have to be reconnected after this change. I failed to see the differences in paths yesterday in the evening.
/root/samba/private
vs.
/var/db/samba4/private

 

[ewhac]

SMB shares work as usual after adding this aux parameter on my system. [ ... ]

This worked for me as well.