Topic: SharedFolders Contrib & Bitkinex winxpclient> HTTP: Method Not Allowed [/folder]

[festus]

References:http://wiki.contribs.org/SharedFolders

I have deployed SharedFolders contrib in my SME Server 7.5.1 and have configured a number of
folders and user accounts. I am also using the WebDAV client 'BitKinex' in Windows XP and for the most
part works very well, when I get over any 'error message' while connecting to a Folder.

For some reason, another folder configured with similar parameters my not raise any error.
There is some ambiguity as to what configuration exactly needs to be changed to fix the error.

I am documenting as many details as possible in this post so that the developer and other users can
provide me with some useful directions to resolve this hurdle.

a) My deployment environment
-----------------------------------
SME Server 7.5.1

sme/server-manager/
Collaboration > Shared Folders

Configure 'Groups' Read or Read/Write config

SMB Access = Enabled, browseable
Recycle bin = disabled
Retention time = unlimited

Web Access = Entire Internet (password required)
WebDav support = enabled
Force secure connections = enabled
Indexes = disabled
Dynamic content execution (PHP, CGI, SSI) = disabled

b) ERROR Message while connecting from BitKinex to the Shared Folder
--------------------------------------------------------------------------------
HTTP: Method Not Allowed [/folder]

connection log has the following lines:
------------------------------------------
Resolving host name 'domain.com'
Connecting (domin.com:443 => ip: 192.168.70.80, port 443
Connected (192.168.70.80:443)
SSL negotiation
Server certificate found in the local database
<<< PROPFIND /folder/HTTP/1.1
<<< Host: domain.com:443
<<< User-Agent: BitKinex/3.2.3
<<< Accept: */*
<<< Pragma: no-cache
<<< Cache-Control:no-cache
<<< Depth: 1
<<< Content-Length: 220
<<< Content-Type: text/xml
>>> HTTP/1.1 405 Method Not Allowed
>>> Date: Tue, 12 Apr 2011 05:16:45 GMT
>>> Server: Apache
>>> Allow: GET,HEAD,POST,OPTIONS,TRACE
>>> Content-Length: 236
>>> Content-Type: text/html;charset=iso-8859-1

Connection Closed
--------------------------------------------------------------------------------------------------------
c) BitKinex Configuration:
-----------------------------
I have tried the following configurations:

Configuration A
----------------
Shared Folders Server Address:
domain.com:443
Security = SSL

Configuration B
----------------
Shared Folders Server Address:
domain.com
Security = SSL
------------------------------------------------------------------------------------
Certain occations, the 'Configuration A' works without error
and other times the 'Configuratioin B' works without error

------------------------------------------------------------------------------------
I am not sure if the error clears up after some time due to some cache

But I need a 'sure way' to resolve this issue so that I know what causes
the error and what configuration will permanently resolve the problem and clear the error.

Would very much appreciate from the Developer of the Contrib or from other experienced
users who understand the issues and can advise me a good solution.

I can provide additional information, if needed..

Best Regards,

Festus

[Daniel B.]

Hi. You should enable indexes on this share, and the error will go away. Let me know if it fixes your issue.

Regards, Daniel

[festus]

Hi Daniel,
Thanks so much for the prompt response.
I have in fact configure one shared folder enabling index and another without enabling index and tested both config.
I still get the error. If I can retrieve any log file, I can copy it and upload for your analysis.
Let me know if I need to check any other configurations.
Best Regards,
Festus

[festus]

Dear Daniel,
I have referred to your contrib page: http://wiki.contribs.org/SharedFolders
I have tried to check the back end configuration to check the actual parameters set for each shared folder.
I am wondering if some cache somewhere is causing the problems I am experiencing.
I want to try disabling the cscPolicy and OpLocks and see if it brings in more reliable access to the shared folders.
I see the following parameters when I use the 'db show' command to view the settings for a particular shared folder.

[root@server /]# db accounts show folder123
folder123=share
    DynamicContent=disabled
    Indexes=disabled
    Name=Test Folder
    ReadGroups=gpc06,gpc07,gpc08,gpc09,gpc10
    RecycleBin=disabled
    RecycleBinRetention=unlimited
    RequireSSL=enabledReadGroups=gpc06,gpc07,gpc08,gpc09,gpc10
    WebDav=enabled
    WriteGroups=gpc01,gpc02,gpc03,gpc04,gpc05
    httpAccess=global-pw
    smbAccess=browseable

Would appreciate if you can clarify the following for me:

a) I do not see any entry for:
    cscPolicy
    OpLocks

For testing purpose, Is it ok to disable cscPolicy using db command and make new entries here ?
Is the correct command:

"db accounts setprop folder123 cscpolicy disabled"

And can i configure to disable cscpolicy in one place for all the shared folders instead of having to do folder by folder ?

b) I have the following groups with read only right:
ReadGroups=gpc06,gpc07,gpc08,gpc09,gpc10

But from BitKinex windows client, I am able to write to the folder as a user in gpc06, gpc07 etc.!!
Could you think of any possible causes I can investigate ?

Thanks for your support.

Best Regards,
Festus

[festus]

Hi Daniel,

Want to provide some additional information on the folder ownership and rw status for the shared folders directory structure. I am wondering if part of my problem is due to wrong ownership and rw config.

/home/e-smith/files/shares/sfolder1/files

drwxrwx---+ 3 root admin 4096 Apr 12 08:19 .
drwxrwx---+ 3 root admin 4096 Apr  8 10:38 ..
drwxrwx---+ 2 root admin 4096 Apr  8 10:38 Recycle Bin
-rw-rw----+ 1 www  admin   10 Apr 12 08:19 test.txt

[root@server files]# cd ..
[root@server sfolder1]# ls -al
total 20
drwxrwx---+  3 root admin 4096 Apr  8 10:38 .
drwxr-xr-x  53 www  www   4096 Apr  8 11:47 ..
drwxrwx---+  3 root admin 4096 Apr 12 08:19 files

[root@server sfolder1]# cd ..
[root@server shares]# ls -al
total 416
drwxr-xr-x  53 www  www   4096 Apr  8 11:47 .
drwxr-xr-x   8 root root  4096 Sep 28  2010 ..
drwxrwx---+  3 root admin 4096 Apr  8 10:38 sfolder1
drwxrwx---+  3 root admin 4096 Apr  8 10:36 sfolder2

[root@server shares]# cd ..
[root@server files]# ls -al
total 32
drwxr-xr-x   8 root  root  4096 Sep 28  2010 .
drwxr-xr-x   9 admin admin 4096 Apr 13 07:31 ..
drwxr-xr-x   3 root  root  4096 Jan 16 02:33 ibays
lrwxrwxrwx   1 root  root    33 Jan 16 02:33 primary -> /home/e-smith/files/ibays/Primary
drwxr-xr-x   5 root  root  4096 Mar 16  2006 samba
drwxr-xr-x   3 root  root  4096 Sep 28  2010 server-resources
drwxr-xr-x   2 root  root  4096 Mar 18 05:22 .shadow
drwxr-xr-x  53 www   www   4096 Apr  8 11:47 shares
drwxr-xr-x  92 root  root  4096 Sep 28  2010 users
[root@server files]#

Please advise.

Best Regards,
Festus

[festus]

Hi Daniel,

While searching for contribs.org for anyone else experiencing problems similar
to mine, I came across the following 'bug report'

http://bugs.contribs.org/show_bug.cgi?id=6250

"The user belonging to the group with read only permissions is able to write in
the folder, as the other users belonging to the groups with r/w permissions.
I don't understand this situation....Antonio"

Your analysis and recommendation as entered in the bug reports is:

"Comment 1 daniel 2010-09-30 04:11:03 MDT
---------------------------------------------------------------------
You seem to have done a lot of modification with custom templates, so please,
check that you can reproduce the issue without all these changes

Also please, show the output of the following commands:

mount

I think the problem is the way you've symlinked the directory files in /mnt/
You may have to just directly mount your hard drives in
/home/e-smith/files/shares/sharename/files (and don't forget to add the acl
option in fstab) ...Daniel"

I was eager to see the rootcause and fix. But the issue is still open and
there is no further posings.

My problem also appears to be very similar to Antonio's, except that my configuration
is very basic without all that Antonio had done.

Further, I also discovered that, with some of the user accounts attached to
a group, the user is able to write into a shared folder to which the group
is not even given access in the control panel configuration!!

My sME 7.5.1 is installed in a VPS.

I am posting below the output I get from my 'mount' command:

[root@server /]# mount
/dev/mapper/main-root on / type ext3 (rw,usrquota,grpquota,acl)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw)
/dev/md1 on /boot type ext3 (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
[root@server /]#

I am not sure if I have to add my issue also to the bug report, or create
a new bug report in order to get some focused assistance..

'Shared Folder' is an excellent contrib that is so useful for many in the SME
community and I really hope with my reports, we will be able to establish
the root cause and fix that can  benefit the community.

I do hope, Daniel you will also be able to spare some time to help us to
debug this issue and help to find a solution. I can also provide you with
remote access to one of my servers with the Shared Folders installed, that
you can login and check out the root cause. This may be the most efficient
way to debug without burdening you too much. Let me know.

Hope to find a solution soon.

Best Regards,
Festus

[Daniel B.]

Further, I also discovered that, with some of the user accounts attached to
a group, the user is able to write into a shared folder to which the group
is not even given access in the control panel configuration!!

Please, update bug 6250 if you have the same problem. I asked the reporter more info, and I didn't get any reply.

[festus]

Thanks Daniel,
Will update the bug 6250

Best Regards,

Festus

[dimvin]

Hi Festus

I can address one of your issues. I just installed the bitkinix client which works well. At this stage I havent tested the report that non auth'd users can read or write, I will test this shortly and get back to you.

b) ERROR Message while connecting from BitKinex to the Shared Folder
--------------------------------------------------------------------------------
HTTP: Method Not Allowed [/folder]

Your error is caused by

Configuration A
----------------
Shared Folders Server Address:
domain.com:443
Security = SSL

Configuration B
----------------
Shared Folders Server Address:
domain.com
Security = SSL

try this configuration:
Shared Folder Server Address = domain.com/shared-folder-name/
Security = SSL

The issue you have is that you are trying to connect with webDAV to the Primary folder which doesnt have webDAV enabled as per the shared-folders contrib, nor is this the location of the "root" folder for your webDAV folders... There is no root, they are all seperate shares with webDAV enabled. Make sure you include the / at the end or it will be looking for a file called shared-folder-name in the Primary directory.

Once you have connected to your webDAV share you can map other webDAV shares, go to DATA SOURCES in the client (this is for the Bitkinix client), select properties and select the site map tab. From here you can add a new path. You will see the first (existing) path is "/shared-folder-name/" which is the share you set up initially. Now add "/shared-folder-2/"  in the path input, choose webDAV as the location specifier, click the ADD tab and wella you can now view both folders in the one menu tree..

and here is the warning.. while testing this I had a user with read/write access.. I clicked on my /shared-folder-2/ in the tree menu and deleted it, thinking i was just removing this folders path from the tree menu.. It didn't remove the path, it deleted the whole file from the server even though it had root/admin rights. The recycle bin I had set up doesnt work for the shared-file obviously.

Now for a little bit of research to find out how to protect the file from users with write permission as it is the reason for using webDAV.. something that won't get over written when the server is updated. Anyone got any ideas..?

Cheers
dimvin

vin, a little bit dim.

[Daniel B.]

and here is the warning.. while testing this I had a user with read/write access..

I clicked on my /shared-folder-2/ in the tree menu and deleted it, thinking i was just removing this folders path from the tree menu.

Are you saying you could delete the root of the shared-folder ? If so, please, open a bug

It didn't remove the path, it deleted the whole file from the server even though it had root/admin rights. The recycle bin I had set up doesnt work for the shared-file obviously.

Recylcle Bin only works for samba access

Now for a little bit of research to find out how to protect the file from users with write permission as it is the reason for using webDAV.

I don't understand what you want. If you give a user write access through webdav, it's normal he can add/delete/modify existing files (except if he can delete the root of the share, this is obviously a bug). If you don't want user to do this (and if you only want them able to download files), just disable WebDav, put the files you want as admin through samba, and let the other user download it with simple http(s).

[dimvin]

Hi VIP-ire

Can I assume VIP-ire that you are theee 'daniel'.. the author of the contrib?
Thank you for your community effort. Impressive list of associated contribs.

and here is the warning.. while testing this I had a user with read/write access.. I clicked on my /shared-folder-2/ in the tree menu and deleted it, thinking i was just removing this folders path from the tree menu.. It didn't remove the path, it deleted the whole file from the server even though it had root/admin rights.

Are you saying you could delete the root of the shared-folder ? If so, please, open a bug

Thats exactly what happened. The directory 'files' was deleted from /home/e-smith/files/shares/shared-folder/

Please let me offer my apologies re the bug, I know the procedures. I have been a silent witness here for the best part ten years, but I must admit I have never contributed my feeble knowledge. I thought this would probably be relevant to your current bug 6250 and by presenting the information here it allowed a solution to the topic, added to the bug and hopefully made this page useful to others. There are already enough pages here that would be better served in the recycle bin..

I don't think its appropriate to open a new bug for acl issues while an outstanding bug on the same subject and contrib exists.

And on that note, I wanted to do more research, to see if the client respects the acl of the webDAV. The issue may be the client not the server although the deletion of the root directory in the share suggests a faulty implementation of the acl.

It didn't remove the path, it deleted the whole file from the server even though it had root/admin rights. The recycle bin I had set up doesnt work for the shared-file obviously.

Recylcle Bin only works for samba access

Understood hence the obvious comment, but once again I probably wasn't clear that I understood this. This is a good oportunity to make others aware and to possibly discuss the features of your contrib. Users could be forgiven for thinking it works in the webDAV environment as it is visable there. Is there a method for hiding the recyle bin in the webDAV folder while having it visable in the smb environment? Is there a method for relocating a copy of a file prior to it being deleted from the webDAV folder? The latter would be an awesome feature to failsafe the webDAV folder.

I also saw you mention somewhere that you had thought about the ability to have an upload feature. A PHP upload script built in to the contrib would be a good way around client apps and or dodgy windows implementations and would go a long way towards a small simple document system for the sme focus of the project.

Now for a little bit of research to find out how to protect the file from users with write permission as it is the reason for using webDAV.

I don't understand what you want. If you give a user write access through webdav, it's normal he can add/delete/modify existing files (except if he can delete the root of the share, this is obviously a bug).

Yes. Ability to add/delete/modify is a normal behaviour given read/write access. I wasn't clear in my reference to 'protect the file from users', this should have read 'protect the directory root'. I want to use the webDAV feature so files can be updated remotely, but the ability to delete the root directory of the share is a major malfunction as you just pointed out.

If you don't want user to do this (and if you only want them able to download files), just disable WebDav, put the files you want as admin through samba, and let the other user download it with simple http(s).

I am using the shared-folders to perform this function for non file admins also, with webDAV only being used by those responsible for maintaining the file contents. The acl ability is great for seperating user groups, however I need to do some more testing to make sure the acl is working so files are not leaked to non auth'd groups' users and that an accidental delete on the directory root doesn't send all contents to file 13.

Thanks once again for your effort Daniel. I'm heavily loaded with work but I will provide testing feedback where I can.

Regards



dimvin

vin, a little bit dim.

[Daniel B.]

Can I assume VIP-ire that you are theee 'daniel'.. the author of the contrib?

You can assume, I'm Daniel, the author of the contrib

Thats exactly what happened. The directory 'files' was deleted from /home/e-smith/files/shares/shared-folder/

Ok, I've just tried this and indeed, it's possible to delete the root directory if you have write access. I'll try to fix this ASAP.

I thought this would probably be relevant to your current bug 6250

No, bug 6250 is about ACL not honored through samba, and is a separate bug (not fixed yet because I couldn't reproduce the issue). You should open another bug for this problem with webdav.

Is there a method for hiding the recyle bin in the webDAV folder while having it visable in the smb environment? Is there a method for relocating a copy of a file prior to it being deleted from the webDAV folder? The latter would be an awesome feature to failsafe the webDAV folder.

Hidding the RecycleBin should be an easy fix, you can open yet another bug for this.

I also saw you mention somewhere that you had thought about the ability to have an upload feature. A PHP upload script built in to the contrib would be a good way around client apps and or dodgy windows implementations and would go a long way towards a small simple document system for the sme focus of the project.

I don't really like the idea of putting PHP here, I've added webdav support exactly for enabling upload of files without having to add this kind of thing.

Regards, Daniel

[dimvin]

I thought this would probably be relevant to your current bug 6250

No, bug 6250 is about ACL not honored through samba, and is a separate bug (not fixed yet because I couldn't reproduce the issue). You should open another bug for this problem with webdav.

I'm away for work at the moment, pretty limited for time. Will look at adding the bug when I return next week but apart from samba vs webDAV the issue appears to be the same.

I think there may be a broader ACL issue than samba not honouring read/write rules. I had five min today so did a quick test and was able to read/write the webDAV with a read only client. If I get another five tomorrow I have another test to try.. To check if any smeserver authorised user can log in with read/write access regardless of the ACL settings.

Is there a method for hiding the recyle bin in the webDAV folder while having it visable in the smb environment? Is there a method for relocating a copy of a file prior to it being deleted from the webDAV folder? The latter would be an awesome feature to failsafe the webDAV folder.

Hidding the RecycleBin should be an easy fix, you can open yet another bug for this.

Intercepting delete and redirecting to move to the recycling bin, therefore enabling a recycling bin in both samba and webdav would be a much more useful feature. I'll have a look at this.. once again when I can find five.

I also saw you mention somewhere that you had thought about the ability to have an upload feature. A PHP upload script built in to the contrib would be a good way around client apps and or dodgy windows implementations and would go a long way towards a small simple document system for the sme focus of the project.

I don't really like the idea of putting PHP here, I've added webdav support exactly for enabling upload of files without having to add this kind of thing.

What webDAV client do you use Daniel?

Aversion to PHP for security reasons? I think its a great contrib,  but the ability to have a self sufficient system can't be overlooked. I sent the webDAV client to a staff member at a remote site just as a little spot test on 'standard end users'. The client app was too much for them to send me a single file. It is only one client and I should probably look at others... If there was a php header that could be turned on/off above the directory listing with upload script to the current folder... Another one for me to look at when I get back...

Regards dimvin

[Daniel B.]

Will look at adding the bug when I return next week but apart from samba vs webDAV the issue appears to be the same.

Even if the symptoms are the same, the issue is different, Samba uses posix ACL, whereas webdav uses a list of allowed user in httpd.conf. If you have the same problem with both samba and webdav, I suspect the problem is not in the contrib but in group membership.

Intercepting delete and redirecting to move to the recycling bin, therefore enabling a recycling bin in both samba and webdav would be a much more useful feature

Sure, but probably much harder to implement

What webDAV client do you use Daniel?

I use Nautilus (Linux only)

Aversion to PHP for security reasons? I think its a great contrib,  but the ability to have a self sufficient system can't be overlooked. I sent the webDAV client to a staff member at a remote site just as a little spot test on 'standard end users'. The client app was too much for them to send me a single file. It is only one client and I should probably look at others... If there was a php header that could be turned on/off above the directory listing with upload script to the current folder.

The only problem here is that WebDav support in MS Windows is just a joke (like to whole system BTW ), and there's not a lot of alternative clients. It's a shame, because WebDav could replace FTP most of the time, and is easier to secure (HTTPS).

I would prefere not adding a PHP based upload form for the following reson:
- PHP support on each share is optional
- A shared-folder should only be a data-store, with different access based on what the admin want, but not an application in itself

Maybe I'll add a PHP form (at least a how-to in the wiki page) as it seems a lot of people (including my own clients) have problem with webdav access.

[Daniel B.]

I've fixed the problem with the root folder deleted through webdav access (if you remove the root folder with a webdav client, it'll delete all the content of the share, but not the root itself).

I've also integrated another contrib with shared folders called Ajaxplorer, which will make file management easier, through an intuitive web based interface (and the permissions available in this web based interface will be based on those defined on the share). This will only be available on SME8, because it requires a recent version of PHP

All this is available in the latest release in smetest repo, with some other improvement (like encryption of shared folders), I'll announce it when it's a bit more tested.