Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1]
1
Installation and Upgrades / Re: Radius "Login incorrect" and LDAP "Connection refused"
« on: June 23, 2014, 08:53:42 pm »
I have the same problem.
In the log file /var/log/freeradius/radius.log appears the following error:
I tried from Windows, android with no success....
In the log file /var/log/freeradius/radius.log appears the following error:
Code: [Select]
Mon Jun 23 13:37:39 2014 : Auth: Login incorrect: [..user...] (from client 10.79.81.250/32 port 0 via TLS tunnel)
Mon Jun 23 13:37:39 2014 : Auth: Login incorrect: [...user...] (from client 10.79.81.250/32 port 0 cli D0-22-BE-55-C6-9E)I tried from Windows, android with no success....
2
Installation and Upgrades / Re: SAMBA Error
« on: March 19, 2014, 03:55:44 pm »
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???
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???
3
Installation and Upgrades / Re: OpenVPN download bundle fails 3.4
« on: March 17, 2014, 11:20:48 pm »
I have the same problem. Do you have any date for releasing the 3.6?
4
Installation and Upgrades / Re: SAMBA Error
« on: November 23, 2013, 01:27:33 am »
Is there any update on when this will be fixed???
5
Installation and Upgrades / Re: SAMBA Error
« on: November 13, 2013, 07:41:53 pm »
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.
$ 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.
6
Installation and Upgrades / Re: SAMBA Error
« on: November 13, 2013, 02:38:31 am »
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.
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.
7
Installation and Upgrades / Re: Zentyal 3.2.3: Backup says it's complete, but no files backup up
« on: October 29, 2013, 06:55:37 pm »
The problem is if you try to INCLUDE "/", it gives you an error message, that / is included by default. Yet, it seems that the default / backs up only the root volume.
We back up both with the default zentyal backup and on top of that we have crashplan installed which backs up off-site and to another local box (qnap running headless crashplan).
We back up both with the default zentyal backup and on top of that we have crashplan installed which backs up off-site and to another local box (qnap running headless crashplan).
8
Installation and Upgrades / Zentyal 3.2.3: Backup says it's complete, but no files backup up
« on: October 29, 2013, 12:20:35 am »
After we upgraded from 2.2 to 3.2 (now 3.2.3), the backup stopped backing up files. Before the upgrade the full backup backed up about 500GB of data compressed full backup files.
After the upgrade the backup seem to complete without problems (no error messages). However a full backup created only one 2.5 MB file + manifest file. So obviously something was wrong. In the end we traced it to Exclude / Include files configuration:
Our Exclude Included looks like this:
Type Exclude or Include
Exclude path /var/lib/firebird/2.5/data
Exclude path /var/tmp
Exclude path /var/cache
Exclude path /var/spool
Exclude path /tmp
Exclude path /media
Exclude path /mnt
Exclude path /sys
Exclude path /proc
Exclude path /dev
This produced EMPTY backups with NO errors.
Then we tried to add / (root). But zentyal complained that / is added by default and can be only Excluded. So I suspect that / is being backed up
To solve the problem we had an INCLUDE of each of the mounts (/home2, /usr, /var, /home, /boot)
root@...:/var/log/zentyal# mount
...
/dev/mapper/vg1-home2 on /home2 type ext4 (rw,usrquota,grpquota,acl,user_xattr)
/dev/mapper/vg0-tmp on /tmp type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-usr on /usr type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-var on /var type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-home on /home type ext4 (rw,usrquota,grpquota,acl,user_xattr)
/dev/mapper/vgboot-boot on /boot type ext4 (rw,acl,user_xattr)
After adding the INCLUDE of each mount point, the system started backing up the files.
This is in a way a problem, because before the upgrade (version 2.2) was backing up every file without having to list each mount point as INCLUDE. After the upgrade (3.2) without changing anything in the backup configuration, zentyal stopped backing up the files without any Errors. There may be many unaware of this problem as there are no errors in the log file.
After the upgrade the backup seem to complete without problems (no error messages). However a full backup created only one 2.5 MB file + manifest file. So obviously something was wrong. In the end we traced it to Exclude / Include files configuration:
Our Exclude Included looks like this:
Type Exclude or Include
Exclude path /var/lib/firebird/2.5/data
Exclude path /var/tmp
Exclude path /var/cache
Exclude path /var/spool
Exclude path /tmp
Exclude path /media
Exclude path /mnt
Exclude path /sys
Exclude path /proc
Exclude path /dev
This produced EMPTY backups with NO errors.
Then we tried to add / (root). But zentyal complained that / is added by default and can be only Excluded. So I suspect that / is being backed up
To solve the problem we had an INCLUDE of each of the mounts (/home2, /usr, /var, /home, /boot)
root@...:/var/log/zentyal# mount
...
/dev/mapper/vg1-home2 on /home2 type ext4 (rw,usrquota,grpquota,acl,user_xattr)
/dev/mapper/vg0-tmp on /tmp type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-usr on /usr type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-var on /var type ext4 (rw,acl,user_xattr)
/dev/mapper/vg0-home on /home type ext4 (rw,usrquota,grpquota,acl,user_xattr)
/dev/mapper/vgboot-boot on /boot type ext4 (rw,acl,user_xattr)
After adding the INCLUDE of each mount point, the system started backing up the files.
This is in a way a problem, because before the upgrade (version 2.2) was backing up every file without having to list each mount point as INCLUDE. After the upgrade (3.2) without changing anything in the backup configuration, zentyal stopped backing up the files without any Errors. There may be many unaware of this problem as there are no errors in the log file.
9
Installation and Upgrades / Re: SAMBA Error
« on: October 24, 2013, 06:13:30 pm »
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.
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.
10
Installation and Upgrades / Re: SAMBA Error
« on: October 24, 2013, 05:35:21 pm »
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.
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.
11
Installation and Upgrades / Re: SAMBA Error
« on: October 12, 2013, 11:38:13 pm »
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...
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...
12
Installation and Upgrades / Zentyal's samba does not respect hide unreadable in smb.conf
« on: August 08, 2013, 11:33:32 pm »
Hello,
I am trying to hide the shares from users that don't have access. After reading lots of posts about samba, the parameters which should do this are
access based share enum = Yes
hide unreadable = Yes
These parameter were added to /usr/share/zentyal/stubs/samba/smb.conf.mas after which the generated /etc/samba/smb.conf file contains:
[global]
workgroup = ....removed...
realm = ...removed...
netbios name = cubo1
server string = Zentyal File Server
server role = dc
server role check:inhibit = yes
server services = s3fs, rpc, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate
server signing = auto
interfaces = lo,eth0
bind interfaces only = yes
log file = /var/log/samba/samba.log
access based share enum = Yes
hide unreadable = Yes
hide dot files = Yes
Yet, the users without access can still see the shares. I even tried to add the same parameters in the definition of the Shares; also with no results. Even the "hide dot files" does not work (users can see .config files which we have in some directories).
Can someone please help.
Thanks.
I am trying to hide the shares from users that don't have access. After reading lots of posts about samba, the parameters which should do this are
access based share enum = Yes
hide unreadable = Yes
These parameter were added to /usr/share/zentyal/stubs/samba/smb.conf.mas after which the generated /etc/samba/smb.conf file contains:
[global]
workgroup = ....removed...
realm = ...removed...
netbios name = cubo1
server string = Zentyal File Server
server role = dc
server role check:inhibit = yes
server services = s3fs, rpc, wrepl, ldap, cldap, kdc, drepl, winbind, ntp_signd, kcc, dnsupdate
server signing = auto
interfaces = lo,eth0
bind interfaces only = yes
log file = /var/log/samba/samba.log
access based share enum = Yes
hide unreadable = Yes
hide dot files = Yes
Yet, the users without access can still see the shares. I even tried to add the same parameters in the definition of the Shares; also with no results. Even the "hide dot files" does not work (users can see .config files which we have in some directories).
Can someone please help.
Thanks.
Pages: [1]