Posts by votdev

Thanks for your investigation. The bug has already been fixed some long time ago in the 0.6 branch which is based on Debian Wheezy. OMV 0.5.x is based on Debian Squeeze, thus it does not require that fix.

Can you execute one of this rsync job manually to get the error message?

What version you are using? Note, 0.6 blocks users after 3 incorrect logins.
What is the exact error message? Does the browser give you some error messages, e.g. incorrect JS code or something else?

Ich denke Dashboard ist mittlerweile ein Wortdas keiner Übersetzung mehr bedarf, zumindest im IT Bereich.

OMV does not Set hdparm parameters itself, instead only the hdparm config file is set. I will implement such a script based on the archlinux howto. The script should be auto generated based on the config.xml information.

The error messages tells you that a service for the filesystem with the ID '201EFB2E1EFAFB9A' is already defined. This can only happen if your config.xml database is corrupt. Can you please provide a WebGUI screenshot from the file systems section? Additional the relevant config.xml content that looks like

<fstab>
			<!--
			<mntent>
				<uuid>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx</uuid>
				<fsname>xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx|xxxx-xxxx|/dev/xxx</fsname>
				<dir>/xxx/yyy/zzz</dir>
				<type>ext2|ext3|ext4|xfs|jfs|iso9660|udf</type>
				<opts></opts>
				<freq>0</freq>
				<passno>0|1|2</passno>
			</mntent>
			-->
		</fstab>

would help us to identify your problem. The file can be found at /ect/openmediavault/config.xml.

It's worth to have a look here, too: https://wiki.archlinux.org/ind…cally_set_again_on_resume

Quote from "tekkbebe"

It is a degraded raid array.

No it isn't, the filesystem is corrupted:

mount: Structure needs cleaning

See here how to fix that:

http://www.sysadminslife.com/l…rbehebung-im-dateisystem/ (German)
https://bugzilla.redhat.com/show_bug.cgi?id=624293
http://ubuntuforums.org/showthread.php?t=1533249

You should do it this the OMV way using

/etc/default/openmediavault

OMV_NUT_UPSMON_DEADTIME=20
OMV_NUT_UPSD_MAXAGE=20

Set pollinterval=15 via the WebGUI in the driver config field.

Using this workflow prevents you from overriding your changes when the config files are generated by OMV.

Quote from "Morgennebel"

From my feeling the issue is one step before, during the creation of the /dev/md0 device. Should not the webgui add the newly created mirror into the <storage>-container in config.xml?

No, nothing is stored in the config.xml because MDADM and LVM devices are auto-detected by the system without any config done by OMV. The only config file that is modified is /etc/mdadm/mdadm.conf (this is done after the creation of the RAID via WebGUI).

According to this page (https://packages.debian.org/wheezy/amd64/hdparm/filelist) hdparm already installs some scripts that are executed automatically by the pm-utils package.

Don't know why your md0 is mounted to /mnt/tmp, but this is the problem why the /dev/md0 device is not shown in the file system creation dialog.

I assume it is a collectd 'df' plugin issue which will wake up the drive if collectd checks the file system usage.

Try

# postfix check
# postfix set-permissions

Note, 'postfix set-permissions' might not run correctly on Debian, but maybe it will fix your issue.

Check /var/log/apache2/openmediavault-webgui_error.log for any hints.

Das fakeraid hat wohl irgendwelche Header auf der Platte hinterlassen die OMV mittels 'blkid' identifiziert und deshalb als in Verwendung klassifiziert. Die Platten mittels der WebGui löschen sollte helfen das Problem zu lösen, ansonsten muss das Handbuch oder Google weiterhelfen wie man die Metadaten des fakeraid los wird.

Quote from "tekkbebe"

Volker, would it not be better to add the official repo for OC 6?? That way upgrades would appear normally in the updates section of the web-gui. I take it you setup your own repo for the plugin. The official repo could be added to OMV Extras too.

No this is a bad idea to use the official ownCloud package repo. If we use the ownCloud package via OMV repos we have the full control about this and only publish a ownCloud package thats works with the OMV plugin. If a user thinks he must use the latest version he is free to install this from the official ownCloud repositories, with all it's disadvantages like a not harmonizing OMV plugin.

A static configuration has sometimes such disadvantages. As you can see the WebGUI has a small subset of configuration options which are used to generate a config that should fit the most users needs. Note, you'll run in the same proplem with commercial products like Qnap or Synology. Your requirement is too specific to reflect them with a simple and minimal configuration UI.

The OC version is fixed to the version in the OMV repository (currently 6.0.3), but you are free to install the latest version yourself without warranty.

The OMV user/group extension for ownCloud denies the creation/modification/deletion of users and groups, but i am not able to block the generic functionality, thus my plans to forbid this can not be fullfilled. This is one of various issues that should be fixed as soon as possible. Creating users and groups in different places is not good and should be forbidden.

Changing passwords should also forbidden from within ownCLoud, but as mentioned above this does not really work. As far as i understood the OC sourcecode the generic user/group backend stores them in the sqlite database, regardless if the OMV user/group backend extension denies this. I did not found any solution/way to deny this OC behaviour. I think OC is not designed for such a scenario/workflow.

In summary the following was/is planned:

- user/groups can only be managed via the OMV webgui
- passwords can only be managed via the OMV webgui

Sadly both intentions are not working at the moment.

Have alook here, maybe this helps you to cutomize the WebGUI to your needs: http://sourceforge.net/p/openmediavault/code/1137
This will be introduced in 0.6.0.10.