On 03/07/2013 01:25 PM, Tornóci László wrote:
On 03/07/2013 11:49 AM, Dirk Kastens wrote:
Hi,
seems that this was the wrong place.
Why? Did you truncate the oc_ldap_user_mapping table?
Could have been that something was left in the Cache, too.
Owncloud still used the UUID for
the user
Hi,
seems that this was the wrong place. Owncloud still used the UUID for
the user directory. Meanwhile I have changed line 431 in
user_ldap/lib/connection.php from
if(!in_array($this-config['ldapUuidAttribute'], array('auto',
'entryuuid', 'nsuniqueid', 'objectguid'))
to
On 03/07/2013 11:49 AM, Dirk Kastens wrote:
Hi,
seems that this was the wrong place. Owncloud still used the UUID for
the user directory. Meanwhile I have changed line 431 in
user_ldap/lib/connection.php from
if(!in_array($this-config['ldapUuidAttribute'], array('auto',
'entryuuid',
Hi,
If I understand your problem correctly, you don't need to change the
source at so many places. There are many things here that can be easily
mixed up:
1. uid to login
2. internal ID for OC
3. user home dir path
4. display name
Your problem was that from OC5 the LDAP entryUUID was used for
On 02/27/2013 08:56 AM, Dirk Kastens wrote:
Hi Arthur,
The problem is, that all other attributes may change (and may be not
unique) in the directory server.
At least, in our user management the uid is unique and never changes. It
is the same across all databases, be it LDAP, AD, or SQL. So I
Hi Arthur,
You can patch it yourself by replacing
the line
https://github.com/owncloud/core/blob/master/apps/user_ldap/lib/access.php#L317
with
$intname = $isUser ? $this-sanitizeUsername($this-readAttribute($dn,
'uid')) : $this-sanitizeUsername($ldapname);
Great! I didn't know that this is
Hi Arthur,
The problem is, that all other attributes may change (and may be not
unique) in the directory server.
At least, in our user management the uid is unique and never changes. It
is the same across all databases, be it LDAP, AD, or SQL. So I did
prefer the old owncloud configuration.
Hi,
the LDAP backend is now using the entyUUID attribute to store users.
(tech detail: the uuid attribute will be autodetected, e.g. AD uses a
different one)
This could be a problem if you change your ldap server, maybe from
openldap to AD or to Novell. Although the user data are the same
On Tuesday, February 19, 2013 20:35 CET, Arthur Schiwon bli...@owncloud.com
wrote:
Depends on where you tackle it. If you ensure uniqueness on LDAP side,
you are not getting a problem on ownCloud as long as you don't use other
user backends (which may have other problems). In some cases
On 02/19/2013 09:19 AM, Dirk Kastens wrote:
Hi,
the LDAP backend is now using the entyUUID attribute to store users.
(tech detail: the uuid attribute will be autodetected, e.g. AD uses a
different one)
I
don't know if this is such a good idea. Now, if you share a file, the
entryUUID is
On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com
wrote:
I configure CN as the display name attribute. But display
names are not unique. So it's not possible to find the right user.
It's true that display names are not unique. But would it help to number
On 19.02.2013, at 08:55, Andreas Ergenzinger
andreas.ergenzin...@uni-konstanz.de wrote:
On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com
wrote:
I configure CN as the display name attribute. But display
names are not unique. So it's not possible to find the
On 02/19/2013 04:38 PM, Andreas Ergenzinger wrote:
On Tuesday, February 19, 2013 15:09 CET, Frank Karlitschek
fr...@owncloud.com wrote:
An admin can disable the option for users to change the display
name. I depends on the user scenario if this is useful and save or
Very good. I agree that
On 02/19/2013 02:55 PM, Andreas Ergenzinger wrote:
On Tuesday, February 19, 2013 12:36 CET, Arthur Schiwon bli...@owncloud.com
wrote:
I configure CN as the display name attribute. But display
names are not unique. So it's not possible to find the right user.
It's true that display names
On Wednesday 13 February 2013 16:43 Patrick Heller wrote:
Get an Error that my Web Server is not properly set it up.
Your web server is not yet properly setup to allow files
synchronization because the WebDAV interface seems to be broken.
Please double check the installation guides
On Wednesday 13 February 2013 11:37 Frank Karlitschek wrote:
I'm very happy to announce the alpha 1 of ownCloud 5
Shouldn't we also announce pre-releases on http://owncloud.org/news/ ?
The more testers, the merrier ;)
--
Med venlig hilsen / Best Regards
Thomas Tanghus
Agreed.
But owncloud.org/news/ is just a blog aggregator. So all that is needed is
someone writing a blog post. Everybody can help with that ;-)
Frank
On 17.02.2013, at 12:58, Thomas Tanghus tho...@tanghus.net wrote:
On Wednesday 13 February 2013 11:37 Frank Karlitschek wrote:
I'm very
Hi All,
I tried to install the own cloud Alpha Version on my QNAP.
Get an Error that my Web Server is not properly set it up.
Your web server is not yet properly setup to allow files
synchronization because the WebDAV interface seems to be broken.
Please double check the installation
Am 13.02.2013 20:18, schrieb Arthur Schiwon:
On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still
work:) (I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
Oh, what happened with an empty group filter? Could you file a bug
report,
On 02/14/2013 01:01 PM, Holger Angenent wrote:
Am 13.02.2013 20:18, schrieb Arthur Schiwon:
On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still
work:) (I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
Oh, what happened with an empty
Hi everybody,
I'm very happy to announce the alpha 1 of ownCloud 5
You can download it here:
http://owncloud.org/releases/owncloud-5.0.0-alpha1.tar.bz2
This is alpha quality and it is not recommended to use this in a production
environment. But if you want to help with testing and QA please
Hi,
thank you for this new (test-)version of ownCloud.
I made some first observations:
- the new GUI looks pretty cool
- LDAP does still work :) (I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
- I synced my /lib dir (as an example for a folder with
Hi,
- LDAP does still work :) (I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
Did you make an upgrade installation? I installed OC5 from scratch. LDAP
authentication seems to work but there's a problem with accessing the
user directories. I
I just upgraded my Windows 2008 R2 test server and after the upgrade I am
not able to see the Group Admin tab for all users. and I also have the
following error: Your web server is not yet properly setup to allow files
synchronization because the WebDAV interface seems to be broken. I upgraded
On Wed, 2013-02-13 at 11:16 -0500, Jimmy Liranzo wrote:
and I also have the following error: Your web server is not yet
properly setup to allow files synchronization because the WebDAV
interface seems to be broken. I upgraded from 4.5.6 .
I upgraded from 4.5.6 too and get the same error even
On 02/13/2013 03:58 PM, Holger Angenent wrote: - LDAP does still work:)
(I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
Oh, what happened with an empty group filter? Could you file a bug
report, please?
Cheers
Arthur
On 02/13/2013 04:09 PM, Dirk Kastens wrote:
Hi,
- LDAP does still work :) (I only had to insert objectClass=group in
the group filter. OC4.5 did not really need this)
Did you make an upgrade installation? I installed OC5 from scratch. LDAP
authentication seems to work but there's a problem
Hi,
for some reason I get a blank page after the installer finished. This
happens in every browser. Here are somne logs:
{app:PHP,message:SQLSTATE[23000]: Integrity constraint
violation: 1062 Duplicate entry
'local::\/home\/www\/htdocs\/owncloudtest\/da' for key 2 at
28 matches
Mail list logo
