Description of problem: I try to configure an Webdav access to http://vargas.calenco.com:8284/workspaces/Documentation/content/en/ with the MCC tool. When I want to mount it, I get : mountpoint not found. But the mount point I have specified is present: /mnt/calenco If I continue with the writing of configuration in fstab; then I try: mount /mnt/calenco I get: /sbin/mount.davfs2:/etc/davfs2/secrets:1: malformed line The content of /etc/davfs2/secrets is one line with: /mnt/calenco myusername mypassword How reproducible: New entry in diskdrake --dav Specify server, mountpoint and in options the user and password. Select the option "noauto". Try to Mount. Get the error message. Reproducible: Steps to Reproduce:
Sorry, Yves, I haven't gotten around to trying to get webdav Calenco access in Mageia 3, yet. You had no problems (except for write access when not using webdav with Dolphin) in Mageia 1 and 2, I suppose? @ Docteam members with Calenco access How do you fare in Mageia 3, can you access Calenco with webdav?
CC: (none) => doc-bugs, marja11, yurchor
WebDAV in Dolphin and Krusader works fine (Mageia 3, x86-64). I have not tried to mount Calenco firmly through fstab though (there were severe hangs in Mageia 2). Is it really needed?
I was trying to write the documentation on Webdav access in MCC. As I have not Webdav server locally, I tried with what I knew. But the error is already present before to write the configuration in fstab.
I can see where the problem is If you look at /etc/davfs2/secrets you will see there is a space at the end of the line after the password. Remove that space and it will work. The space is getting there because in /usr/lib/libDrakX/fs/remote/davfs.pm at line 28 a comment parameter is being written after the password. This comment parameter is undefined. Take it out and the file is written OK. What I do not understand is how it has ever worked?
CC: (none) => derekjenn
Hello Derek, I confirm you that the modification at the end line allows to mount the DAV point. If I try from MCC, each time, the secrets file is altered, wrongly. You are on the good way. ;)
This problem is still valid in Mageia 4.
Version: 3 => 4
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
CC: (none) => doktor5000
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: NEW => RESOLVEDResolution: (none) => OLD
Hello, The problem is still valid in Mageia 5
Status: RESOLVED => REOPENEDResolution: OLD => (none)
Whiteboard: (none) => MGA5TOO
What about cauldron? Such bugs should ideally be filed against the development release so that we don't have to EOL each year to reopen them :)
Whiteboard: MGA5TOO => (none)Version: 4 => 5
Indeed.
Whiteboard: (none) => MGA5TOOVersion: 5 => Cauldron
commit 59aa9112f26e7027898fc67b6357379c310e0a38 Author: Papoteur <papoteur@...> Date: Tue Dec 15 10:26:14 2015 +0100 Suppress undefined comment in secrets line mga#10540 --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=59aa9112f26e7027898fc67b6357379c310e0a38
CC: doc-bugs => (none)
Sorry for not having tried before. Just now, when trying the fix with drakxtools-17.15-1.mga6, clicking on "Options" after giving the path to the server and the mountpoint, no longer gives fields to add username and password. IIRC, they were there when I tried before (around Mageia 2, though, so really long ago :-( )
Source RPM: (none) => drakxtools
s/the fix with/this fix that is included in/ (in fact, it was already included before, but I tested with v.17.15
ah, wait, after saving my changes and restarting diskdrake --webdav, the fields do appear. mounting (in the tool) doesn't work, yet, but maybe that only needs another save + restart (or there's a typo in my password or the path to the server... I intend to try again later today, but don't mind if anyone beats me to it ;-)
(In reply to Marja van Waes from comment #15) > mounting (in the tool) doesn't work, yet, but maybe that only needs another > save + restart Didn't try, but rebooted instead (after adding "nofail" in the webdav line in fstab, of course!), because of some vague memory that that didn't work before, either. > (or there's a typo in my password or the path to the > server No, that was correct >... I intend to try again later today less than half an hour is "later", too :-þ Anyway: jan 24 12:30:42 cldrn mount[681]: /sbin/mount.davfs2: Mounting failed. jan 24 12:30:42 cldrn mount[681]: Could not resolve hostname `mageia.calenco.com': Host not found was before: jan 24 12:30:43 cldrn systemd[1]: Starting LSB: Wait for the hotplugged network to be up... so there was no chance that it would get mounted on boot
i've tried some more things, and found that mounting the webdav share using that option in 'diskdrake --dav' works if i don't add the nofail option in fstab. however, i haven't managed to get write access.
(I should have said that I got a message about "nofail" being an unknown option.) The share starts fine on boot after adding "_netdev" to its options in fstab. I left "nofail" out. Writing stays impossible, I've tried not allowing and allowing users to mount the share, setting my gid and uid in the fstab line, not adding and adding the "rw" option (it has never been "ro"). [marja@cldrn_64 ~]$ df | grep CalencoWebDav http://mageia.calenco.com:8284/workspaces/Documentation/content/ 1,3T 763G 509G 61% /home/marja/CalencoWebDav [marja@cldrn_64 ~]$ ls -al | grep CalencoWebDav/ drwxr-xr-x 32 marja marja 3072 dec 1 2011 CalencoWebDav/ [marja@cldrn_64 ~]$ ls -al CalencoWebDav/ | grep test -rw-r--r-- 1 marja marja 658 jun 14 2015 test.xsl -rw-r--r-- 1 marja marja 29666 feb 19 2015 WebHelp-DrakX-test.xsl Every time i tried to edit and save test.xsl, I got an error message "test.xsl" E212: Can't open file for writing I ended up losing the file locally, but it is still visible via the Calenco web interface.
@ papoteur Sorry, I had misread the summary of this report... I thought this was still about write access being missing. Since this is only about access, and read access is possible, I'll close this report. Thanks for your work on it :-)
Status: REOPENED => RESOLVEDResolution: (none) => FIXED
commit 4762bfc751b1b994cb129a80f7eb3424c503a4ea Author: Papoteur <papoteur@...> Date: Sun Jan 24 17:47:51 2016 +0100 suppress a trailing space in writing secrets (mga#10540) --- Commit Link: http://gitweb.mageia.org/software/drakx/commit/?id=4762bfc751b1b994cb129a80f7eb3424c503a4ea
(In reply to Marja van Waes from comment #18) > (I should have said that I got a message about "nofail" being an unknown > option.) > > The share starts fine on boot after adding "_netdev" to its options in > fstab. I left "nofail" out. > > Writing stays impossible, I've tried not allowing and allowing users to > mount the share, setting my gid and uid in the fstab line, not adding and > adding the "rw" option (it has never been "ro"). > > [marja@cldrn_64 ~]$ df | grep CalencoWebDav > http://mageia.calenco.com:8284/workspaces/Documentation/content/ 1,3T > 763G 509G 61% /home/marja/CalencoWebDav > [marja@cldrn_64 ~]$ ls -al | grep CalencoWebDav/ > drwxr-xr-x 32 marja marja 3072 dec 1 2011 CalencoWebDav/ > [marja@cldrn_64 ~]$ ls -al CalencoWebDav/ | grep test > -rw-r--r-- 1 marja marja 658 jun 14 2015 test.xsl > -rw-r--r-- 1 marja marja 29666 feb 19 2015 WebHelp-DrakX-test.xsl > > Every time i tried to edit and save test.xsl, I got an error message > > "test.xsl" E212: Can't open file for writing > > I ended up losing the file locally, but it is still visible via the Calenco > web interface. This should be reported as another bug, if you can confirm that it is in relation to our configuration tools. I can't write file in the Calenco Webdav space : permission denied.
(In reply to papoteur from comment #21) > > This should be reported as another bug, if you can confirm that it is in > relation to our configuration tools. > I can't write file in the Calenco Webdav space : permission denied. I haven't tried to do it differently in cauldron recently, it used to work fine in Mageia when using Dolphin to access a webdav shared directory: no problem at all writing to it, changes got saved and were visible in Calenco. Actually, when bug 3828 was closed, it was still valid when MCC was used to configure the webdav share. The issue was in fact only workarounded by whatever Camille had added so that we could use Dolphin. Note to me: test both (in cauldron), the Dolphin and the MCC way, and reopen, and reassign to our tools, bug 3828 if only the latter still doesn't work
Reopened because it's always in MGA5
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Assignee: bugsquad => mageiatools
Feel free to cherry pick your commits in the distro/mga5 branch...
CC: (none) => thierry.vignaud
Version: Cauldron => 5Whiteboard: MGA5TOO => (none)
The patch is already committed on distro/mga5 (I didn't remember). After this commit some other commits came from Thomas and Thierry (dated 2016-09-25). Should they be incorporated in a new release or not? http://gitweb.mageia.org/software/drakx/log/?h=distro/mga5
Release 2.27 of drakx is now out.