FreeNAS 9.2.1- RELEASE: CIFS: The service could not be started.

[snowy150]

I traced the CIFS non-starting problem to wrong permissions for the .samba4 folder in my main volume after I set permissions recursively. Can anybody tell me what the permissions should be for this folder? I've done a bit of a workaround by changing the samba4 link in the /var/db folder, but would prefer to fix it properly!

 

[Pete Pineda]

I traced the CIFS non-starting problem to wrong permissions for the .samba4 folder in my main volume after I set permissions recursively. Can anybody tell me what the permissions should be for this folder? I've done a bit of a workaround by changing the samba4 link in the /var/db folder, but would prefer to fix it properly!

What was your work around on this? I'm getting the same thing. My samba4 link looks like: lrwxr-xr-x 1 root wheel 17 Feb 15 01:09 samba4@ -> /mnt/BigZ/.samba4

 

[Rand]

For me it was that the samba link in /var/db was pointing to a wrong directory.
As long as that (old share) directory exists i can start samba though.

Have you tried deleting the .samba4 directory and just recreating it with mkdir ?
- all subsequently files where automatically created for me with correct permissions

 

[Pete Pineda]

Fixed it! For me, I saw bug: https://bugs.freenas.org/issues/4194

Then went to the permissions on my mount: /mnt/BigZ/.samba4

Changed the ACL from Unix to Windows and I was able to start CIFS after that. I hope this helps someone!

 

[snowy150]

I was able to get CIFS started by deleting the contents of the .samba4 directory in my main volume, deleting the samba4 link in /var/db, changing the main volume permissions from Unix to Windows and then restarting.

Thanks for the suggestions Rand and Pete.

For me it was that the samba link in /var/db was pointing to a wrong directory.
As long as that (old share) directory exists i can start samba though.

Have you tried deleting the .samba4 directory and just recreating it with mkdir ?
- all subsequently files where automatically created for me with correct permissions

Fixed it! For me, I saw bug: https://bugs.freenas.org/issues/4194

Then went to the permissions on my mount: /mnt/BigZ/.samba4

Changed the ACL from Unix to Windows and I was able to start CIFS after that. I hope this helps someone!

 

[Brad Heightman]

Fixed it! For me, I saw bug: https://bugs.freenas.org/issues/4194

Then went to the permissions on my mount: /mnt/BigZ/.samba4

Changed the ACL from Unix to Windows and I was able to start CIFS after that. I hope this helps someone!

This fixed for me as well

 

[Lucas]

This fixed it for me: https://bugs.freenas.org/issues/4194#note-10
Destroy .samba4 dataset and delete symlink. Toggle cifs to on then the dataset and symlink are recreated by Freenas.

 

[RiBeneke]

This solution of deleting the samba4 directories files and symlink worked for me too.
http://forums.freenas.org/index.php...cannot-start-cifs-after-deleting-jails.18520/

 

[macmino]

It works also for me (same problem of everybody).
Fresh 9.2.1 install. Added zpool, afp share, cifs share. No windows service at all. Applied the bug4194 solutio, works perfectly
Thanks!

 

[Supa]

The output of 'zfs list' command are:
NAME USED AVAIL REFER MOUNTPOINT
volume1/.samba4 2.61M 545G 2.61M /mnt/volume1/.samba4
Thus the line you are referring to is the output of the 'zfs list | grep .samba4' command execution on the line above it (in the original comment).
piping the output of 'zfs list' to grep removes the headers and just displays the line containing '.samba4'

Reported Solutions:

I just ran into this exact error.
I believe it is related to https://bugs.freenas.org/issues/4174
Recursively setting permissions or ownership on volumes that contain system datasets; specifically <volume name>/.samba4
The following fixed the issue for me:
Find and destroy the .samba4 dataset (mine is on 'volume1'):

1. Select 'shell' ### or ssh, putty, etc
2. execute the following commands
   [root@flatline ~]# zfs list | grep .samba4
   volume1/.samba4 2.61M 545G 2.61M /mnt/volume1/.samba4
   [root@flatline ~]# zfs destroy volume1/.samba4
   [root@flatline ~]# rm /var/db/samba4
3. Restart CIFS
   Select 'Services'
   Toggle cifs to 'on' position

cifs should now be up and you should be able to access your shares again.
One can reproduce the failure scenario by the following:
Select 'Storage'
Select volume containing the '.samba4' dataset ### use zfs list to determine which volume; I think it defaults to the first volume
Select 'Change Permissions'
Change 'Owner (group)' to 'mail'
Change 'Type of ACL' to 'Unix' ### if it wasn't already
Check 'Set permission recursively'
Click 'change'
Select 'Services'
Toggle cifs to 'off' position
Toggle cifs to 'on' position ### this did not succeed for me and resulted in the same error as this bug description
The error also occurs when recursively changing the mode or owner (user) of the volume containing the .samba4 dataset such that the sanity check fails.
One could arguably try to set the permissions, user, group, etc of .samba4 and its children back to their original values, but i found just destroying
the dataset and deleting the symlink much easier.

Well what I ended up trying was to change the permissions from UNIX to Windows and now the service is starting fine.​

Recreate the samba directory fixes it again.

mkdir /mnt/test3/.samba4
ls /mnt/test3/.samba4 (to verify it got created)
Once created set to permission 0755

 

[Spannerman]

Afternoon. I came across this thread as I now also have the same problem, although rather weirdly it did not manifest itself immediately when I upgraded to 9.2.1.2. Yesterday some of my file copying using Windows 7 started to go wrong part way through, until today when the file share is inaccessible and I cannot start CIFS at all. In all other aspects my issue looks identical to the discussion above and the report outputs are the same with the samba 4 permissions issue. However I'm worried that there does not seem to be a solution yet. Its rather frustrating having a pool I can see in my shell but which I cannot practically use. Should I submit a bug report too or can I assume that somewhere a solution is being worked on? Thanks a lot.

 

[Spannerman]

Apologies - I did not see the very last section on bug report 4174 and 4194 trying those now.....fingers crossed

 

[Spannerman]

All fixed now. Can highly recommend the solution here: https://bugs.freenas.org/issues/4194

 

[Yatti420]

9.2.1.3 beta should fix the CIFs issues.. It is BETA however..

 

[Spannerman]

Well my system was working well all week, after implementing https://bugs.freenas.org/issues/4194 on my FreeNAS 9.2.1.2. I noticed that the official 9.2.1.3 was available so today I loaded that. Guess what, the SAMBA failure is back, and once more I cannot access my shares except via the shell or similar. I tried destroying the Samba data set again, as prescribed in bug 4194 but now that does not help. I tried checking the permissions on the data set before enabling. I deleted the share and created a new one after destroying the samba data set too. Is there something else I could do? I'm struggling to be diplomatic here but anyone got any more suggestions now. How can a new release make the problem worse? Meanwhile it seems I must go back to 9.2.1.2 and use the 4194 fix. Appreciate any insight. Should I do a fresh install perhaps? Thanks.

Update: haven't tried a fresh install yet, but went back to 9.2.1.2 and the problem persists even after destroying the samba data set. So running out of options. Will try a fresh install of 9.2.1.3 later but have other priorities now this afternoon.

Further update: reset all permissions on the pool using the FreeNAS GUI, and deleted the windows share. Re-added share, cleared the samba4 data set as per 4194 solution. And CIFS is back running. Sweaty afternoon over..... I'm still on 9.2.1.2 and now wary of going to 9.2.1.3 until I see some more debate on what's going on.

 

[downingjosh]

For what it's worth, this issue was caused when I removed the volume on which the system dataset pool was stored (just forgot to move it first). Even after relocating the system dataset pool, the samba4 symlink was still pointing to the old location. Rather than fix the symlink, I recreated the mount point and moved the system dataset pool to the old location. Once the system dataset was once again moved to the new location, the symlink was updated with the correct location and CIFS/samba4 service would start.

Edit: I still had to manually update the /var/log symlink in order for the shares to show up. Before replacing this symlink, I could browse to the server's IP or hostname, but no shares were listed. When starting the samba service, I got the following error:

[root@freenas] /etc/ix.rc.d# service ix-samba start
Traceback (most recent call last):
File "/usr/local/libexec/nas/generate_smb4_conf.py", line 813, in <module>
main()
File "/usr/local/libexec/nas/generate_smb4_conf.py", line 776, in main
smb4_setup()
File "/usr/local/libexec/nas/generate_smb4_conf.py", line 686, in smb4_setup
os.chmod("/var/log/samba4", 0755)
OSError: [Errno 2] No such file or directory: '/var/log/samba4'

Those two symbolic links appear to be the only ones which reference the system dataset pool location. I ran this command to list all symbolic links:

ls -lR / | grep ^l

Let me know if this should be submitted in a bug report. I'm running FreeNAS 9.2.1.3, for reference.