Zentyal Forum, Linux Small Business Server
Zentyal Server => Installation and Upgrades => Topic started by: Russel on September 25, 2013, 04:56:27 am
-
I have been having a tough time getting SAMBA sorted out right on my Zentyal install. After upgrading to Zentyal 3.2 today, I continued to have the same problems. I went in and did a "sudo apt-get remove zentyal-samba", rebooted, and then re-installed it. When I am on the web dashboard and I create a new file share I get notified that there were samba errors. Can someone help me make sense of the errors? These are from /var/log/zentyal/zentyal.log
2013/09/24 21:39:03 ERROR> AuthKrbHelper.pm:172 EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab - Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm BCGVT.LAN
at /usr/share/perl5/EBox/Samba/AuthKrbHelper.pm line 172
EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab('EBox::Samba::AuthKrbHelper=HASH(0x72e2ff0)', 'Administrator', 'BCGVT.LAN', '/var/lib/zentyal/conf/samba.keytab') called at /usr/share/perl5/EBox/Samba/AuthKrbHelper.pm line 116
EBox::Samba::AuthKrbHelper::new('EBox::Samba::AuthKrbHelper', 'RID', 500) called at /usr/share/perl5/EBox/Samba/SmbClient.pm line 47
EBox::Samba::SmbClient::new('EBox::Samba::SmbClient', 'target', 'Thor.bcgvt.lan', 'service', 'Documents', 'RID', 500) called at /usr/share/perl5/EBox/Samba.pm line 286
EBox::Samba::_postServiceHook('EBox::Samba=HASH(0x5433800)', 1) called at /usr/share/perl5/EBox/Module/Service.pm line 968
EBox::Module::Service::_regenConfig('EBox::Samba=HASH(0x5433800)') called at /usr/share/perl5/EBox/Module/Base.pm line 232
EBox::Module::Base::save('EBox::Samba=HASH(0x5433800)') called at /usr/share/perl5/EBox/GlobalImpl.pm line 642
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x3228058)', 'progress', 'EBox::ProgressIndicator=HASH(0x321abe0)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x3225408)', 'progress', 'EBox::ProgressIndicator=HASH(0x321abe0)') called at /usr/share/zentyal/global-action line 39
2013/09/24 21:39:03 ERROR> GlobalImpl.pm:648 EBox::GlobalImpl::__ANON__ - Failed to save changes in module samba: Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm BCGVT.LAN
2013/09/24 21:39:03 INFO> Base.pm:229 EBox::Module::Base::save - Restarting service for module: logs
2013/09/24 21:39:03 ERROR> GlobalImpl.pm:722 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: samba at /usr/share/perl5/EBox/GlobalImpl.pm line 722
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x3228058)', 'progress', 'EBox::ProgressIndicator=HASH(0x321abe0)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x3225408)', 'progress', 'EBox::ProgressIndicator=HASH(0x321abe0)') called at /usr/share/zentyal/global-action line 39
2013/09/24 21:52:31 INFO> GlobalImpl.pm:611 EBox::GlobalImpl::saveAllModules - Saving config and restarting services: firewall samba logs
2013/09/24 21:52:31 INFO> Base.pm:229 EBox::Module::Base::save - Restarting service for module: firewall
2013/09/24 21:52:32 INFO> Base.pm:229 EBox::Module::Base::save - Restarting service for module: samba
2013/09/24 21:52:40 ERROR> AuthKrbHelper.pm:172 EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab - Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm BCGVT.LAN
at /usr/share/perl5/EBox/Samba/AuthKrbHelper.pm line 172
EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab('EBox::Samba::AuthKrbHelper=HASH(0x80a88a0)', 'Administrator', 'BCGVT.LAN', '/var/lib/zentyal/conf/samba.keytab') called at /usr/share/perl5/EBox/Samba/AuthKrbHelper.pm line 116
EBox::Samba::AuthKrbHelper::new('EBox::Samba::AuthKrbHelper', 'RID', 500) called at /usr/share/perl5/EBox/Samba/SmbClient.pm line 47
EBox::Samba::SmbClient::new('EBox::Samba::SmbClient', 'target', 'Thor.bcgvt.lan', 'service', 'Documents', 'RID', 500) called at /usr/share/perl5/EBox/Samba.pm line 286
EBox::Samba::_postServiceHook('EBox::Samba=HASH(0x61a6660)', 1) called at /usr/share/perl5/EBox/Module/Service.pm line 968
EBox::Module::Service::_regenConfig('EBox::Samba=HASH(0x61a6660)') called at /usr/share/perl5/EBox/Module/Base.pm line 232
EBox::Module::Base::save('EBox::Samba=HASH(0x61a6660)') called at /usr/share/perl5/EBox/GlobalImpl.pm line 642
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x3f9b058)', 'progress', 'EBox::ProgressIndicator=HASH(0x3f8dbe0)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x3f98408)', 'progress', 'EBox::ProgressIndicator=HASH(0x3f8dbe0)') called at /usr/share/zentyal/global-action line 39
2013/09/24 21:52:40 ERROR> GlobalImpl.pm:648 EBox::GlobalImpl::__ANON__ - Failed to save changes in module samba: Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm BCGVT.LAN
2013/09/24 21:52:40 INFO> Base.pm:229 EBox::Module::Base::save - Restarting service for module: logs
2013/09/24 21:52:40 ERROR> GlobalImpl.pm:722 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: samba at /usr/share/perl5/EBox/GlobalImpl.pm line 722
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x3f9b058)', 'progress', 'EBox::ProgressIndicator=HASH(0x3f8dbe0)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x3f98408)', 'progress', 'EBox::ProgressIndicator=HASH(0x3f8dbe0)') called at /usr/share/zentyal/global-action line 39
-
i'm having troubles with samba too, i have made a new installation on an old PC for testing... i share a directory but it does not let me write even if told zentyal via web interface to do so. It does not change owner and folder Permissions on /home/samba/shares/shared_folder you have to do it manually >:(
-
ok i just made a clean installation, everything was ok.... but after zentyal updates was done (even after restarting) is when come out the error:
The following modules failed while saving their changes, their state is unknown: samba
and stop to set up right permissions in /home/samba/shares folder....
why testing updates in a stable release? what are you thinking?
just stay away from updates
-
I'm getting a similar error after yesterday's zentyal-samba updates.
My installation is a fresh install, everything was smooth until yesterday, now this error prevents me from saving my conf and also making a config export.
2013/09/25 22:03:14 ERROR> Backup.pm:146 EBox::Backup::__ANON__ - Could not get ticket: could not acquire credentials using an initial credenti
als context: unable to reach any KDC in realm DOMAINNAME.LAN
at /usr/share/perl5/EBox/Backup.pm line 146
EBox::Backup::_dumpModulesBackupData('EBox::Backup', '/var/lib/zentyal/conf//backup.w5239z/aux', 'changesSaved', 1, 'bug', 0, 'fallback
ToRO', 0) called at /usr/share/perl5/EBox/Backup.pm line 88
EBox::Backup::_makeBackup('EBox::Backup', 'time', 1380157388, 'description', 'Backup', 'fallbackToRO', 0, 'bug', 0, ...) called at /usr
/share/perl5/EBox/Backup.pm line 747
EBox::Backup::makeBackup('EBox::Backup') called at /usr/share/zentyal/make-backup line 91
-
i also have this problem :(
-
hi guys,
I've just found a work around.
step 1: Delete the module "File Sharing and Domain Services" and if you have "Printer Sharing Service"
step 2: apt-get remove samba4
step 3: apt-get purge samba4
step 4: Install again the module "File Sharing and Domain Services" and "Printer Sharing Service"
This works for me. hope this works to you guys. no guarantee.
Thanks
-
@paulreynand With this workaround you lost something? Configurations, shares, profiles?
-
good question there. yes, i've lost something. my shares. but i can easily put it back since the folders are intact in /home/samba/shares/. also i can get the list of acl's via "getfacl /home/samba/shares/to-my-folder". this might be tedious for others have a lot of shares.
i suggest get first the list of acls on every directory before putting it back on share configuration.
thanks
-
Hi,
I have a similar problem (my version is Zentyal 3.2 , with samba module 3.2.2):
I can not save the changes made to shares, the save operation is not completed, the system remains idle at the rate of 67% with the message "Saving Changes in modules, current operation: saving samba module; 2 of 3 operations performed" .
I followed the help of "paulreynard", but for me it did not work.
I can not access to created share;
in the / var / log / Zentyal / zentyal.log I find this error:
LDB.pm: 334 EBox :: LDB :: __ANON__ - Error loading OU 'Domain Controllers' in 'testdomain DC =, DC = lan': LDAP error: The client attempted to add an entry That already exists. This can occur as
a result of
* An add request was Submitted with a DN That already exists
* To modify DN requested was Submitted, where the requested new DN already exists
* The request is adding an attribute to the schema and an attribute with the
Given OID or name already exists
. <br/> Operation parameters: {
'attr' => [
'objectclass',
[
'organizationalUnit'
],
'ou',
'Domain Controllers'
]
Thanks
-
hi @jakeelwood,
i also seen that before i do the work around. After i reinstall the removed and purged module, it did not came up again. So im not sure the log you're seeing is an error prior the work around. Another thing is that i found that there is a /opt/samba4, im thinking if you could delete that after the purge to make sure that all samba4 components are gone before installing it again. You can give it a try. I'm assuming that your're doing it on a test environment.
Thanks
-
everybody please determine if you are using 32bits or 64bits distribution?
-
64 bits
-
64bit working
-
Hi,
I'm using the 64-bit version.
Thanks for the advice @paulreynand !
I am afraid that by removing/purging samba I could make things worse as this is a production server... but if there's no other way, I might just do that as well.
-
64 bit version.
Thanks to paulreynard for the reply , but :
I repeated the procedure, removing the folder /opt/samba4.
When I reinstall the module "file sharing", saving crashes to 75%!
The module file sharing "appears" to be installed but does not work.
I attach screenshot and zentyal.log
-
If you are really stuck with a live system. the phpldapadmin or webmin and see if you can find if there is a duplicate ? ! last straw support
-
A possible solution is shown here:
http://forum.zentyal.org/index.php/topic,18180.msg70162.html#msg70162
Problem with DNS resolve in the ubuntu System.
Change nameserver-IP in /etc/resolv.conf to the Zentyal-Server-LH-IP (127.0.0.1) may help.
Regards
-
On a test environment I upgraded from 3.0.27 to 3.2 well. I had 4 test users, 2 test groups, PDC, GPO's (default domain policy and another policy for one user group), one share. All working after upgrade and reboot. At first the samba module did not start, threw [fail] after upgrading, but after reboot it worked fine. That was x64 release.
I will make more tests tho so I can try upgrading my production 3.0 machine sometime.
-
I am having similar issues with samba after the 3.2.2 upgrade . My original problem of users being deleted along with their emails has gone away. No, my problem is that the webadmin assigns a default group 3000002 with rwx access to all the shares, but a search in my ldap tree gives me nothing for that id. Removing it with a setfacl -dR command gives me access to the shares. I am also getting the 'already existing' errors in my zentyal.log file. Anyone know what group 3000002 is supposed to be?
-
Thanks paulreynand, the steps you provided solved my one of my SAMBA problems, now I am working through the rest. Thanks again.
-
Hi Guys,
I've tried to reproduce the issue. This time, my first work around is not working. But another work around i found.
step 1: Try to disable and enable the "File Sharing and Domain Services" module on the "Module Status" and save the changes (expect an error)
step 2: Go to "Dashboard" and restart the "File Sharing" module (expect an error)
step 3: Go to root shell and run "service zentyal samba stop" (it should stop successfully w/out error, else repeat step 1 & 2)
step 4: Finally, reboot and check every thing.
I've tried this a couple of times just to be sure that it works when ever this happens.
Hope this works for you guys.
Thanks
-
thanks @paulreynand for your help!!!....
I'm making my tests in an old PC before installation to a real server. So i was thinking there must be a problem about the delay that some process have to respond and some zentyal scripts and their time limits (there may other issues too).... i have installed zentyal 3.2 32bits several times and must of the times just a recent install, samba was doing what is suppost to do, but i have noticed in some installations that after clamav db get updated, it starts to show errors on samba changes.... i have been using top and i've been watching that clamav uses a lot of memory ( a lot for my old PC with 896MB in RAM) and noticed that swap was growing very fast. As my hards disks are slow (2 old 40GB IDE) i started to think... why just reapplied several times the changes in samba so all theses procedures will be cached in RAM next time i'll try to apply. So far by now is working. So my workaround is:
- If you have installed zentyal on an old slow machine with less than 1.5Gb RAM
- Reapplied several times samba changes until you get no error (at least 3 times in my case). I usually tick & untick guest access on any share to reapply changes
Notes: i'm having my two old 40GB hard disk on a linux kernel raid0 to try to gain some performance and i still need to repplied changes several times in samba must of time to get it done. BTW, guest access on shared folders have never worked for me don't allow any user to access :(.
-
step 1: Try to disable and enable the "File Sharing and Domain Services" module on the "Module Status" and save the changes (expect an error)
step 2: Go to "Dashboard" and restart the "File Sharing" module (expect an error)
step 3: Go to root shell and run "service zentyal samba stop" (it should stop successfully w/out error, else repeat step 1 & 2)
step 4: Finally, reboot and check every thing.
Hi @paulreynand, thanks for the workaround!
I did not try it yet. Just to make sure, when you disabled/enabled File Sharing and Domain Services module you lost your shares and permissions, right?
The reason I ask is because I've already created around 20 shares each one with different sets of permissions per user/group, would be a pain having to re-do that all over again.
Regards,
-
@rpro disabling samba module will not loose your shares
-
Can someone post the file that is in /etc/init.d/samba4 ?
When i try to enable samba after purge and install again it gives me :
sudo service zentyal samba restart
* Restarting Zentyal module: samba [fail]
root command /etc/init.d/samba4 stop failed.
Error output: /var/lib/zentyal/tmp/IwnWKGLDTJ.cmd: 1: /var/lib/zentyal/tmp/IwnWKGLDTJ.cmd: /etc/init.d/samba4: not found
Command output: .
Exit value: 127
Thks
-
I find the file in my production server and have copy the thing, now everything is ok, i can see the shares, but the guest access is not possible http://trac.zentyal.org/ticket/7380
Now I've another problem, In 3.0 i use kerberos, and the MAC users can connect to the server, browse the home folders and the shares. Now they only can see the shares, not the home folders. Have i to reexport again the /homes in the server and make a new kerberos ticket?
-
My windows users can't find a login server after upgrading to 3.2. Somehow, after a timeout, they do get logged in. They can see the samba share, but cannot access any of the mapped drives that go to windows servers.
I'm getting this in the log:
2013/10/03 15:59:05 ERROR> AuthKrbHelper.pm:172 EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab - Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm subdomain.domain.com
2013/10/03 17:23:14 ERROR> Service.pm:990 EBox::Module::Service::__ANON__ - Error restarting service: Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm subdomain.domain.com
2013/10/03 17:23:14 ERROR> RestartService.pm:67 EBox::SysInfo::CGI::RestartService::__ANON__ - Restart of File Sharing from dashboard failed: Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm subdomain.domain.com
I've noticed the the dashboard says there are updates, but the update module do not show them. So, I went to the command line and updated:
sudo apt-get update
sudo apt-get upgrade
After this, I rebooted and Windows Workstation user became able to login. And, they became able to access some of the file shares located on both Windows servers and Zentyal servers. However, one of my Zentyal file shares with Guest access was no longer accessible. So I tried to remove the share and re-add it. But, Zentyal could save my changes:
http://neartalk.com/ss/2013-10-03_17:56:06.png
If I disable the "File Sharing" module, Zentyal will successfully save my file share changes, but upon restarting the "File Sharing" module, I get the same error:
http://neartalk.com/ss/2013-10-03_17:56:06.png
2013/10/03 18:31:09 ERROR> GlobalImpl.pm:722 EBox::GlobalImpl::saveAllModules - The following modules failed while saving their changes, their state is unknown: samba at /usr/share/perl5/EBox/GlobalImpl.pm line 722
EBox::GlobalImpl::saveAllModules('EBox::GlobalImpl=HASH(0x96f33a4)', 'progress', 'EBox::ProgressIndicator=HASH(0x96ec694)') called at /usr/share/perl5/EBox/Global.pm line 95
EBox::Global::AUTOLOAD('EBox::Global=HASH(0x96f3070)', 'progress', 'EBox::ProgressIndicator=HASH(0x96ec694)') called at /usr/share/zentyal/global-action line 39
Please help.
-
I think this might have had to do with the Ubuntu Keyrings. I've experience that type of thing before (http://www.howtoadvice.com/KeyringPasswords) when upgrading Ubuntu desktop.
The reason I say this, is because I noticed that this problem went away after I updated from the command line:
sudo apt-get update
sudo apt-get upgrade
This somehow updated modules that could not be seen in the Zentyal's web interface, and I noticed that one of the updates had to do with keyrings.
-
Somehow, after a timeout, they do get logged in
If the home share isn't mounted than the client logged in offline using the stored passwords on the client machine. That normally happens if the DC is not reachable.
-
Hi all (first time post)
I'v been using 3.0.2 (64bits) for sometime now and its been excellent - kudos to all involved. But this recent upgrade to 3.2.2. has been horrid at least in relation to the SAMBA module. I've got exactly the same issue and log messages that Lonniebiz reported and I think I've exhausted all options in relation to a fix. Thanks in any case to paulreynand but those workarounds are unfortunately temporary at best.
I'm tempted at this stage to downgrade back to good ol 3.0.2 until this is resolved, but I'm curious to see (a) this has been reported as a bug - couldn't see it when I searched, or (b) if anyone has found a more enduring fix for this.
The german link was tantalising as it mentioned DNS config as possible culprit but I clean installed from the 3.2 installer so not sure if that applies to me.
By the way I'm loving the openness and general goodwill attitude on these forums, a welcome change, I'm guessing its becuase most of you are IT professionals.
Thanks for any assistance.
Kind regards,
Suthagar
-
@suthagar
Instead of downgrading to 3.0, first try this (this is what I had to do to make it work).
1) Take note of each of your file-shares actual location on the file system. Mine were all at /home/samba/shares.
2) Remove all existing file shares at Zentyal Web Interface > File Sharing > General > Shares. This will not remove the files from the files system; it will only remove the Zentyal samba shares of those folders.
3) Save changes with these file shares removed, and the save will actually succeed this time.
4) Remake each file share. When I did this, I accidentally put the entire path in at first (/home/samba/shares/FolderName), but then, after realizing this, I deleted my file shares again, and this time only put the folder name (FolderName), and Zentyal automatically knew the "/home/samba/shares" part.
5) From the command line, recursively change the permissions of each folder:
sudo chown -R sync:'__USERS__' /location/of/shared/folder/
Lastly, for some reason, when you try to control the access of share folders using: Zentyal Web Interface > File Sharing > General > Shares, if you add a group it won't honor it. You have to add each individual user.
This is clearly a bug, and one that is so ugly I'm sure they're working on this.
I didn't downgrade back to 3.0 myself. I've made the painful changes I've mentioned above and in hopes that an upcoming bug fix will make group access controls work again.
Similarly:
This freenas/zentyal user is having similar problems with Zentyal Group authentication:
https://bugs.freenas.org/issues/3276
-
Apologies as Zentyal 3.2, Zentyal ISO no problems.
The only problem I had with shares was one I maid deliberately off the home folder by specifying a created directory in /srv/shares.
Something I do to escape quota's.
I remember at the time thinking it was probably just a permissions thing so I just creted it as a samba share.
I have done several installs now and haven't had a problem as I am using group access to shares.
I have group folders for most of my groups.
I have folders for software install that use group security.
I did a liitle write up with my own Samba4 gotcha's but for some reason seem to be unable to recreate yours.
I am trying as if Zentyal 3.2 is essentially buggy then I am not going to use it.
Strange thing is I have been really happy and my experience of 3.2 is nothing like 3.0.
3.2 is very new so probably there will be a few hot fixes to come on line but so far for me so good.
Apols for not having a reason why.
-
@Lonniebiz
Thanks very for the reply. I would agree that this is a bug (either with SAMBA or Zentyal's implementation of it) and given that it relates to shares is a major showstopper for production environments. Do you know if a bugtrac has been raised for this?
I tried the process you outlined but it did not seem to work. Steps 1-3 worked as you outlined but the recreation of the shares still resulted in the same error message. A restart of the server did instantiate the shares but I could not access them from a windows 8 client machine - this was done after I gave a single user read write access. I also tried using the shared folder functionality in the Users and Groups but this did not make a difference.
I wonder if there is a permission issue here because your chown rsync command came back with an error saying it could not find the group _USERS_. Does this suggest anything? The share in question (which I moved to under home/samba/shares) did belong to a previous installation and so might of had left over permissions but to be sure I did chmod 777 the whole share. Also samba insisted on creating another home folder so the structure looked like /home/samba/shares/home/shares - which is a little odd. the /home is on its own drive and mounted at boot but I would not think this would make a difference.
@BrettonWoods thanks also for the reply I would agree with you that the best thing to do is to treat 3.2 as an unstable release (for now). I'm going to restore my production environment to 3.02 (with updates) and keep my dev environment at 3.2 to keep trying to resolve the issue.
Grateful for any further advice.
Thanks,
S
-
I wonder if there is a permission issue here because your chown rsync command came back with an error saying it could not find the group _USERS_. Does this suggest anything?
Not _USERS_, and __USERS__, with two _ _
-
@Sand_Man
d'oh! of course it is! I'll try this out and see if Lonniebiz's temp solution works.
Thanks
S
-
Hi all (first time post)
I'v been using 3.0.2 (64bits) for sometime now and its been excellent - kudos to all involved. But this recent upgrade to 3.2.2. has been horrid at least in relation to the SAMBA module. I've got exactly the same issue and log messages that Lonniebiz reported and I think I've exhausted all options in relation to a fix. Thanks in any case to paulreynand but those workarounds are unfortunately temporary at best.
I'm tempted at this stage to downgrade back to good ol 3.0.2 until this is resolved, but I'm curious to see (a) this has been reported as a bug - couldn't see it when I searched, or (b) if anyone has found a more enduring fix for this.
The german link was tantalising as it mentioned DNS config as possible culprit but I clean installed from the 3.2 installer so not sure if that applies to me.
By the way I'm loving the openness and general goodwill attitude on these forums, a welcome change, I'm guessing its becuase most of you are IT professionals.
Thanks for any assistance.
Kind regards,
Suthagar
hi can u explain, how to downgrade to 3.0.2, i have the same problem here..
thnx
-
@Gerick
Hi there, I did a clean reinstall off my existing 3.021 CD. Basically I keep the server OS and the shares / app server / gateway either as separate machines or separate disks on the same machine, so in effect I can exchange one Linux server distro with another if needed. Its been my experience that different releases offer differing degrees of stability / functionality etc.. at different points in time so I don't mind switching between them - its part of the price of using Linux. Mostly I stick with Ubuntu based releases though as many of our desktops are based on 13.04.
I'm not aware of any means of downgrading in-place for any distro. Others may have more knowledge on that than me. Sorry I could not be of more help. I understand from some of the support tickets that a new Zentyal samba module could be in the works (3.2.3 possibly) if I read it correctly. So it maybe worth persevering but again I defer to more experienced and knowledgeable users.
Kind regards,
S
-
Hi all
Success! I re-read Lonniebiz's instructions and I realised the issue I was having was due to the use of a preexisting share. So here's what I did:
1. Fresh reinstall of 3.2 just to be sure (see below)
2. Checked and updated domain controller settings
3. Checked and updated DNS settings and created users (no groups) inc domain administrator as per official documentation
4. Saved modules - all worked including SAMBA (held my breath at the dreaded 67% mark!)
5. Recreated share so that the SAMBA module created a brand new folder under /home/samba/shares
6. Saved module settings again. No errors.
7. Added individual users into share ACL - as per Lonniebiz's notes group level access is broken for now.
8. Saved changes again. No errors.
9. Moved all files from old share location to new location under /home/samba/shares - you may or may not need this step depending on your circumstances. I had an existing share from a previous install.
10. Ran sudo chown -R sync:'__USERS__' /location/of/shared/folder/ as per Lonniebiz's instructions. Please note __ means _ _ together with out spaces (Thanks Sand_man)
11. Ran chmod as required to ensure correct folder permissions at the file system level - again this is specific to my needs you may not need this.
12. Tried joining from a Windows 8 Pro client using the domain administrator I created earlier. Hey presto both user drives and SAMBA shares were accessable and mapped.
Hope that helps other, of course your mileage may vary and I can not take an responsibilty for your specific situation.
Credit really goes to Lonniebiz in the main and Sand_man for the clarification.
Thanks all. Here's hoping for an update bug fix soon so we can go back to using group level access.
Just as an aside all attempts at an in place upgrade from 3.02x to 3.2x were very unsucessful for me at least. The web interface was glitichy and the SAMBA module would fail to start on boot. This could just be my install hence I reinstalled from scratch.
Kind regards,
S
-
We have the same problem. After the upgrade samba stopped working because of permission problems. After you restart samba, the service goes changes ownership root:Administrators (not even sync:__USERS__) and at the same time removes ACLs at the beginning of the process. After some 15 minutes, it times out after finishing maybe half of the shares, leaving the users without access to the other shares. The other problem with this is that the reset process loses the information about who create/modified the file as the owner is reset to root:Administrators.
We were able to find a workaround, but it's not the solution:
1) All of the shares have ACLs with users (without groups) - per Lonniebiz's instructions. This allowed the restart of samba to complete successfully
2) When you make any changes or restart the service, it takes forever as the ownership of files is changed to root:Administrator during the samba restart. After the restart is finished we run setfacl --restore, so that all the files have the ownership changed to the user who modified the file.
3) We have a nightly process with getfacl --absolute-names -R /home/samba/shares (fortunately we had this running for a long time. When there is any change done to share settings or if the samba service is restarted, we have to run the setfacl --restore.
Needless to say, this is big problem and I hope zentyal guys will fix this soon...
-
Hi,
I just wanted to share with you guys: after the latest batch of updates, which included samba4, zentyal-core and zentyal-samba, the problem was fixed. I don't know if the updates addressed this specific bug or it was just a fortunate coincidence that the commands ran during the update fixed the problem.
Here are the versions of the related packages in my system, in case anyone is having the same problem, make sure you are up to date:
ii samba4 4.1.0rc4-zentyal2
ii zentyal-samba 3.2.6
ii zentyal-core 3.2.3
ii zentyal-dns 3.2.3
My best regards.
-
Do these latest updates also make Zentyal honor group permissions (so that you don't have to add each user's permissions individually)? Has anyone tested this yet (after updating)?
-
Hi,
I just wanted to share with you guys: after the latest batch of updates, which included samba4, zentyal-core and zentyal-samba, the problem was fixed. I don't know if the updates addressed this specific bug or it was just a fortunate coincidence that the commands ran during the update fixed the problem.
Here are the versions of the related packages in my system, in case anyone is having the same problem, make sure you are up to date:
ii samba4 4.1.0rc4-zentyal2
ii zentyal-samba 3.2.6
ii zentyal-core 3.2.3
ii zentyal-dns 3.2.3
My best regards.
Do these latest updates also make Zentyal honor group permissions (so that you don't have to add each user's permissions individually)? Has anyone tested this yet (after updating)?
I had tested with Samba 4.1 and apparently, disabling "Antivirus" scanning will fix the long pending issues that are posted here.
Cheers.
-
There are still unresolved issues:
On the filesystem, zentyal still changes the ownership of the files to root:Administrators and there is no way to tell who created and modified the file. We have strict nomenclature rules for filenaming and a process that emails users which modified the files notification to correct the naming. Now all the files are owned by root:Administrator so there is no way to determine who created and who modified any given file.
Secondly, during the startup of zentyal-samba the change of ownership takes some 20-30 minutes and the shares are unavailable during the that process. They come online (available to users who haver permissions) one by one. If you have large shares with many files, this makes it impossible to do any changes to config of zentyal, because you always have the fear that the change will restart samba service and make the shares unavailable for half an hour.
-
There are still unresolved issues:
I would not say these are issues but rather settings not fitting your own design.
1 - What matters in Zentyal design is ACL more than Linux object ownership.
2 - you can still change default behaviour (although this is not available through GUI) so that ACL are not parsed when Samba launches. I already saw multiple posts in this forum relating this.
-
Hi Christian, thank you for the prompt feedback.
The behaviour changed from 3.0 to 3.2. In 3.0, the files certainly were not chowned on samba restart. I agree that ACLs are more important than the Linux filesystem permissions, but even if you do getfacl on any file, you will not get the information who created a file as it will appear as:
# owner: root
# group: Administrators
So during the zentyal samba startup process all the information about file creators is wiped out. This is certainly a behaviour that changed from 3.0 to 3.2.
When you refer to disabling the ACL parsing through non-gui interface, I assume you are refering to uncommenting
#unmanaged_acls = yes
in /etc/zentyal/samba.conf
I have not had time to test it. It seems to me that this will disable the permissions administration through Zentyal's GUI, which is not an optimal solution.
We still want to be able to control the access to shares via Zentyal GUI (that is the ACLs of the shares). Zentyal can control the ACL access to directories and files, but there is no reason for zentyal-samba to reset the ownership (both filesystem and ACL) to root:Administrators, as critical information about who created the file gets lost.
-
@famasa
Well said. It seemed to work better in 3.0, so why did they change this?
In 3.0, it didn't take a long time to save changes to the samba module.
In 3.0, if you set up group permissions, Zentyal honored those permissions for shared folders.
In 3.0, the way it worked made sense.
In 3.2, what are the benefits of these changes that are causing all these problems?
The goal should be to make Zentyal shares act exactly like Windows shares. In 3.0, Zentyal was a fairly decent replacement for a windows file server. In 3.2, so far, controlling permissions has been de-abstracted from the web interface it seems.
-
1 - What matters in Zentyal design is ACL more than Linux object ownership.
No one is arguing this priority. The issue is, for us who have actually upgrade to 3.2, is that is not clear what the Linux-level ownership and permissions should be, in order get Zentyal to again honor the ACL permissions we've prescribed via the web interface.
In 3.0, I believe this is the ownership that worked:
sudo chown -R sync:'__USERS__' /home/samba/shares/FolderName/
I don't care what Zentyal makes the linux-level ownership or permissions as long as it will honor the ACL permissions I set in the web interface. And also, as long as it will allow me to set permissions using windows explorer, while being logged in as a domain admin to a windows server or workstation.
-
After the last update of samba (File Sharing and Domain Services 3.2.9), again after changing any permissions the samba restart hangs at 67% and then all of the shares become unavailable. If you do getfacl on the share it does not have the access priviliges defined in zentyal.
Everytime there is a samba service restart, I have to restore the privileges manually using "setfacl --restore ..."
This is so frustrating. I am very disappointed with the latest zentyal development.
-
Have you done the chmod 0600 /opt/samba4/private/tls/key.pem
(File Sharing and Domain Services 3.2.9) bug
-
The file already had the right permissions:
$ ls -l /opt/samba4/private/tls/key.pem
-rw------- 1 root root 887 Oct 6 17:42 /opt/samba4/private/tls/key.pem
and we continue with the same problem.
-
Same problem with 32-bit 3.2 version
-
Sorry guys as I have File Sharing and Domain Services 3.2.9 running.
samba4 SMB/CIFS file, NT domain and active directory server (version 4) 4.1.1-zentyal2
I have held back on updates and have stopped before the above.
Maybe someone might just inform you of a scheduled fix.
-
Hello there !
Got an issue with the 3.2.9 samba4 update (11/11/13) on my Zentyal 3.2 64Bits.
I Couldn't start de Sharing services anymore even after a hardware reboot.
I corrected this with this command :
chmod 0600 /opt/samba4/private/tls/key.pem
The day after that, the service stopped by it self... again ! I was afraid i couldn't restart it but it did.
In the meantime my users were not able de log on the domain !
To avoid this situation i created the following script :
#!/bin/sh
#Automatic restarting SAMBA4 service if down
pidof smbd > /dev/null
if [ $? = 1 ]
then
/etc/init.d/samba4 restart
echo "Samba service restarted" | mail -s 'Samba restarted on XXX Server' myemail@domain.com
fi
I've added this entry in the /etc/crontab file :
*/1 * * * * root /root/smbrestart.sh
...so that every minute my script is launched. Anytime Samba server stops, within the minute it's automatically restarted and i'm informed by email.
If it can help somebody ;)
-
Is there any update on when this will be fixed???
-
I have the same error, using 32 bits though
-
I believe I've made some progress on this issue. I no longer receive this error
AuthKrbHelper.pm:172 EBox::Samba::AuthKrbHelper::_getTicketUsingKeytab - Could not get ticket: could not acquire credentials using an initial credentials context: unable to reach any KDC in realm BCGVT.LAN
at /usr/share/perl5/EBox/Samba/AuthKrbHelper.pm line 172 in the zentyal.log anymore.
After do a LOT of googling and looking through the perl scripts the trace references I found this linke: http://kerberos.996246.n3.nabble.com/kinit-krb5-get-init-creds-unable-to-reach-any-KDC-in-realm-REALM-td9947.html (http://kerberos.996246.n3.nabble.com/kinit-krb5-get-init-creds-unable-to-reach-any-KDC-in-realm-REALM-td9947.html) and it refers to the /etc/hosts file where the machine name is set to 127.0.1.1 when it should be 127.0.0.1.
And I actually read up on some of the kerberos info from an M$ website: http://technet.microsoft.com/en-us/library/bb463167.aspx (http://technet.microsoft.com/en-us/library/bb463167.aspx) and this: To access Kerberized services, the client computer must be capable of resolving the DNS domain of the target computer to the correct Kerberos REALM. This becomes an issue when the DNS domain name does not match the Kerberos REALM name. Because mapping does not become an issue until the client computer tries to access a service, domain to REALM mapping problems do not affect initial ticket requests (TGTs). When mapping problems exist, service ticket requests may fail or access to Kerberized services may fail. With Active Directory, the REALM name is always the uppercase equivalent of the DNS domain name.
paragraph stood out to me.
After reading that I remembered that I continue to experience DNS issues. So I set the domain IP address, added the server as a host name and my DNS server as a host name. I assigned the two IP addresses I use on my server to the host name and added both as name servers.
I also read on http://kerberos.996246.n3.nabble.com/kinit-krb5-get-init-creds-unable-to-reach-any-KDC-in-realm-REALM-td9947.html (http://kerberos.996246.n3.nabble.com/kinit-krb5-get-init-creds-unable-to-reach-any-KDC-in-realm-REALM-td9947.html) that kerberos uses ports 88 and 750 so I added them to the 'Network' > 'Services' > 'Kerberos' using TCP & UDP protocol and saved the configuration. I then added those same ports to the services record in DNS.
After making these changes I am now left with this error in the zentyal.log file, which I thought was already fixed.
2013/12/05 20:49:06 ERROR> GlobalImpl.pm:660 EBox::GlobalImpl::__ANON__ - Failed to save changes in module samba: Failed to open: NT_STATUS_ACCESS_DENIED at /usr/share/perl5/EBox/Samba.pm line 412.
The Zentyal Web GUI still stops at 67% and throws an error and I'm unable to start the zentyal samba service but samba4 is running; I am able to access my shares without any issues.
I can easily back out my changes if I'm headed in the wrong direction...
-
This is getting really frustrating. 4 months later, the problem has not been resolved:
We are currently at Zentyal 3.3 with:
Core 3.3.5
File Sharing and Domain Services 3.3.4
Every time you make any changes through the interface you have to worry whether Filesharing (samba) is restarted as dependency. If that happens the interface hangs at 67%, all of the shares are disabled until the ACLs are applied. If you are lucky it finishes but mostly it does not. Then you have to go and restore manually the ACLs from backup setfacl --restore
This is really no way to administer a filesharing server... How much longer do we have to wait for a fix???
-
Its not a fix famasa,
Only thing I can think of is jump to 3.4.
Its not an upgrade though its a config backup. File backup. Install and restore affair.
The community version is a rolling road and I have no idea when or if there will be a fix for 3.3.4.
I am presuming 3.4 is still very much in focus and if you want something quick then thats your answer.
-
Hi.... It's not a problem....
domain administrator account password has expired ))))
sudo samba-tool user setpassword administrator
And ales.....
-
Thank you sergowech
Solved my issue