webdav rights management
I have a really big problem here and it has to do with the way the administrator rights are allocated in webdav.
We have let's say 10 users, and they are split up into two different groups.
Webdav infostore has two folders to be shared, one for the one group and one for the other group.
now... in the netdrive/webdrive client i log in every user as himself and achieve that every user only sees the share for his group!
this is cool, works great and looks sexy.
now...if one user creates a new folder in the share, this user alone gets the administrator rights on the new folder...and allthough the other users in the same group see the new folder and are able to open it...they are not allowed to delete or rename it, nor, which is even worse, are they allowed to delete or rename any files inside this folder !
get the point ?
now the question is: how do we get around this...this way a normal working in different teams is impossible !!!
A possible solution could be, to not login in netdrive/webdrive as the individual ox-user but to log in as a new webdrive-group_one respectively webdrive-group_two user.
This way every user in a group logs in as this new groupish-webdrive user.
This should result in every group-user to have all administrator right on everything this group should get their fingers on !
sounds sensible ?
For this to work though...and this is where you come in :-)...we'd desperately need a possibility to change the rights of the allready built file-tree to the new webdrive-group_user recursively ! Because changing the rights of every folder in the ox-gui one after another is a pain in the a**...
Any chance this could be done ?
desperately in need of help...
Thanks a lot!
Last edited by tafkaz; 02-08-2008 at 01:40 PM.
ok....forget the recursive rights setting...
i found out that doing following would do the job:
if i just copy all the data from the old share to a new folder as this newly created webdav-group-one-user, all the rights for all the directories are perfect.
but the problem now is, that i cannot seem to cleanly copy data to this new share...it always stops in the middle with various error messages.
trying to copy locally with davfs for example brings this :
cp -r /mnt/webdav/group-one-folder/foo /mnt/new-webdav-group-one-folder/
cp: cannot create regular file `/mnt/new-webdav-group-one-folder/foo/foo.bar': File exists
needless to say the file doesn't exist in reallity...
Using Konquerors webdavs:// gives me the unexpected error 200...
in both ways the folders are created first (with perfect rights), but it doesnt seem to copy any of the files...
any idea ?
Thanx in advance
Looks like somehow there are some files which cant be reached anymore (or have really vanished?)
this is what the ox-gui tells me when i want to open one of those files:
11.02.2008 15:51-->Fehlermeldung: FileStorageException für FileStorage mit id 3 in Kontext 1 . Zugrundeliegende Meldung ist: FLS-0003 Category=5 Message=An IO error occurred: /var/opt/open-xchange/filespool/1_ctx_store/00/14/95 (No such file or directory) exceptionID=-138841464-158. Prüfen Sie den StackTrace (FLS-0004,-138841464-160)
Ok...found following here...
so...if i got this right, i am supposed to change the rights for /var/opt/open-xchange/filespool/1_ctx_store, as the rights are actually set to root.root:
chown -R open-xchange.open-xchange /var/opt/open-xchange/filespool/1_ctx_store
Is this a sensible thing to do ?
and btw. the file /var/opt/open-xchange/filespool/1_ctx_store/00/14/95 among others actually really does not exist... does that mean, the file is gone forever and only has a db-entry that makes me believe the file is still there, or is it the other way round, the file is still there aomewhere, but the db-entry is faulty ?
Last edited by tafkaz; 02-11-2008 at 06:59 PM.
I still have the same problem here....and it seems to be growing...
Now i found out this:
in my /var/opt/open-xchange/filespool/1_ctx_store/ there are two folders. 00 and 01
00 is 33 GB big and 01 is only 1.3 GB big.
and the creation date of 01 is 2008-02-08... The date of the last working backup of the files i have...
Spooky, heh ?
now....any ideas with this new information anyone ???
1. what are the correct rights for /var/opt/open-xchange/filespool/1_ctx_store/ ?
(i have root:root)
2. what folders should be in /var/opt/open-xchange/filespool/1_ctx_store/ ?
( i have 2 folders: 00 & 01 from wich 01 is much newer and has exactly the date my last working backup is from...)
btw: i backup mounting the webdav-share with davfs2 and then using storeBackup....
i think i found what's wrong...still need help though...
ok...after 2 weeks of log-reading, discussing with developers, talking in different irc-channels, here's what i think could be the real problem:
- i have a file foo.bar in a webdav-folder
- now i copy foo.bar to another webdav location, i can use any client for this, you can try konqueror for example
- the copy will be generated perfectly
- now i delete the copy from the copy-location, the original file remains untouched, still using a client
Now this is the incredible but true result:
- if i login to the ox-gui and go to the infostore location of the orginal file foo.bar i can see it's there. But when i click on it to download the file i get something like:
23.02.2008 20:58-->Fehlermeldung: FileStorageException für FileStorage mit id 3 in Kontext 1 . Zugrundeliegende Meldung ist: FLS-0003 Category=5 Message=An IO error occurred: /var/opt/open-xchange/filespool/1_ctx_store/00/21/f0 (No such file or directory) exceptionID=2085957265-1193. Prüfen Sie den StackTrace (FLS-0004,2085957265-1195)
the file /var/opt/open-xchange/filespool/1_ctx_store/00/21/f0 has vanished !
As i didn't do anything to the original file, other than copy it to another location, this is a bit surprising, don't you think ?
This behaviour is absolutely reproducable...
maybe someone has an idea now ???
Thanx in advance
I tried this with another Installation also:
and i have the same problem.
The two versions are:
Build: 0, 2007-12-11 09:31:01
Build: 6.4.2-0, 2008-02-19 11:03:28
Looks like i found a really bad bug...
Last edited by tafkaz; 02-24-2008 at 12:50 PM.
thanks for all that investigation, i'll try to reproduce this and will file a bug report then.
Thank you very much!