Beiträge von writzthecat

Can you give some more details ?

Im running VDR 2.0.3-1~etobi1 on OMV 1.15. I also have the DVBAPI and VNSISERVER plugin and it's running fine for my rapsi and Zotac Box to connect from OpenElec.

etobi built ?! VDR 2.2.0-1 and it's plugins only for Jessie kernel and not for Wheezy. I don't think he is going to do the whole work again and build everything for wheezy again, but feel free to ask him.

Also i don't think OMV is going to perform a kernel upgrade to Jessie in the near future, as the last kernel upgrade to wheezy is not that old, but you will have to ask the DEVS of OMV if they plan and upgrade.

I've seen others building lates VDR for wheezy (https://launchpad.net/~sven-6/…ndex?field.series_filter=), but i have not tried it yet as for me 2.0.3.1 is working without problems.

solved with first purge everything and then reinstalled plex addon

Sry guys to disturb you,

after recovering a lot of my files i reinstalled everything today.

Now im facing the same error i had in november again.

Plex Addon 1.0.7 running

Failed
to execute command 'omv-mkconf plexmediaserver 2>&1': chown:
Zugriff auf „/var/lib/plexmediaserver“ nicht möglich: Datei oder
Verzeichnis nicht gefunden

Failed
 to execute command 'omv-mkconf plexmediaserver 2>&1': chown: 
Zugriff auf „/var/lib/plexmediaserver“ nicht möglich: Datei oder 
Verzeichnis nicht gefunden


Fehler
 #4000:
exception 'OMVException' with message 'Failed to execute command 
'omv-mkconf plexmediaserver 2>&1': chown: Zugriff auf 
„/var/lib/plexmediaserver“ nicht möglich: Datei oder Verzeichnis nicht 
gefunden' in 
/usr/share/openmediavault/engined/module/plexmediaserver.inc:44
Stack trace:
#0 /usr/share/openmediavault/engined/rpc/config.inc(180): 
OMVModulePlexMediaServer->applyConfig()
#1 [internal function]: OMVRpcServiceConfig->applyChanges(Array, 
Array)
#2 /usr/share/php/openmediavault/rpcservice.inc(125): 
call_user_func_array(Array, Array)
#3 /usr/share/php/openmediavault/rpcservice.inc(158): 
OMVRpcServiceAbstract->callMethod('applyChanges', Array, Array)
#4 /usr/share/openmediavault/engined/rpc/config.inc(224): 
OMVRpcServiceAbstract->callMethodBg('applyChanges', Array, Array)
#5 [internal function]: OMVRpcServiceConfig->applyChangesBg(Array, 
Array)
#6 /usr/share/php/openmediavault/rpcservice.inc(125): 
call_user_func_array(Array, Array)
#7 /usr/share/php/openmediavault/rpc.inc(79): 
OMVRpcServiceAbstract->callMethod('applyChangesBg', Array, Array)
#8 /usr/sbin/omv-engined(500): OMVRpc::exec('Config', 'applyChangesBg', 
Array, Array, 1)
#9 {main}

Hello,

as im setting up my OMV Sytem again, i wont to be sure to have created the correct shares.

Here is what i want:

1. Shared folder called "media" -> This folder will have a few subfolders. "Media" and it's subfolders should have : Read / Write for Administrators and Users. Read and Execute for Guests without password
2. Shared folder called "docs" -> This folder will have a few subfolders. "docs" and it's subfolders should only have Read / Write for Administrators and Users.
3. Shared folder called "upload" -> This folder should have read / write for Everybody.

The last times i tried it i had no access as guest to anything.

Can you please tell me the correct settings for my configuration when i create the shared folder and when i create the network share ?

Thank you in advance!

Zitat von Solo0815

Good to hear, most of your stuff is back!

I'll test photorec and extundelete in a VM also and report back. Additionally there is "ext4magic".
Let's see, which is the best one

I gave it a try today with:

ext4magic /dev/sde1 -M -d /mnt/backup/recover/disk1

The only thing happend was :

root@sysresccd / % ext4magic /dev/sde1 -M -d /mnt/backup/recover/disk1
Warning: Activate magic-scan or disaster-recovery function, may be some command line options ignored

Since them nothing is happening...i took the paramters i found on: http://ext4magic.sourceforge.n…en.html#Recovery_examples

Forget about it.....it took about 90 minutes and now started...let's see what is happening

going to test ext4magic and will report back.

I guess with SnapraidFix it has overwritten a lot. Maybe with out this command it would have worked with extundelete aswell.

the real advantage of extundelete was it recovered the names and directories aswell, but the result was maybe 10 % of the lost data.

With Photorec it's perfect. The only thing i do not understand, my *.mp3 files are still having their tags, so with mp3 tag i can recover the name.

My movie and also *.jpg files have also been "tagged" but lost their tags during recovery.

I gotta find out why, cause if i would be able to give them a tag that can be recovered Photorec would be my bread and butter in file recovery

Recovered almost all of the Pictures!

Also 90 % of the Movies.

With the TV Series i guess im going to drop it. I would have to watch every single file in order to find out wicht Series , Season, Episode

But the Pictures where really important ( wedding; etc)

Ty for your help!

PS: Any news for the new Aufs version ? Maybe i should wait with installing everything new till its here

Hm..

i tried it two times with extundelete and it has restored only a few files.

I now did it with Photorec, and it restored "maybe" everything. But it will take a long time for me to sort all the media files, as they have no name and no directory....

with all the files its: Unable to restore inode "filename" reallocationg free disk space

i excluded /storage/ because Snapraid always gaves me errors while syncing.

The idea putting the pool folder on the parity drive is a good one.

I will keep it in my mind.

BTW: extundelete was not able to restore any single file this is really bad

Hello Solo,

/storage/ is the pool folder created by aufs.

So the content of this folder is splitted onto three disk in the folders D1 D2 and D3.

Therefore i thought i have to exclude /storage/

It's working, but a lot of "Unable to restore inode"

At least i now know how to be better prepared for the future :-/

blkid

/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="be149662-abd5-4d5d-b532-14d091321812" TYPE="ext4" PARTUUID="000397bf-01"
/dev/sda5: UUID="5d31da78-38c9-48e7-8aa0-bfa5c4b18235" TYPE="swap" PARTUUID="000397bf-05"
/dev/sdb1: LABEL="Backup" UUID="c7692c8e-2a3e-4ac2-b954-29c71ac43df9" TYPE="ext4" PARTUUID="abbbbcb7-4831-4c62-b4ce-b8eefa757578"
/dev/sdc1: LABEL="DISK3" UUID="858099db-5680-44d7-8cd3-79134be2157c" TYPE="ext4" PARTUUID="571fd11d-2fe9-46a0-a45e-32bfd5a677ef"
/dev/sdd1: LABEL="DISK2" UUID="2f914808-85f6-4b9b-aee3-43cfad784960" TYPE="ext4" PARTUUID="e563015a-431e-488a-93ea-30960db9df19"
/dev/sde1: LABEL="DISK1" UUID="0722de2e-cf4b-4a63-aece-f01f502b7c27" TYPE="ext4" PARTUUID="da3e312c-be1c-42b3-bd40-810f5be6ce4b"
/dev/sdf1: LABEL="Parity1" UUID="a7f543ef-6a8f-41f9-ac83-942085c9bfca" TYPE="ext4" PARTUUID="c206d942-0953-4b93-bb1b-2239a8c42fe7"
/dev/sr0: UUID="2014-11-17-18-17-22-00" LABEL="sysrcd-4.4.1" TYPE="iso9660"

Seems to be the same

Yep,

no output.

But i guess i found the problem. my virtual Device with SystemRescueCd disconnected....

Im now trying it again and restarted the server, booting SystemrecueCD with docache command

Will i have to check for the disk again or will they still be the same after restart ?

I used this iso :SystemRescueCd-x86-4.4.1

root@sysresccd /mnt/backup/recover/disk1 % extundelete --version

mount
rootfs on / type rootfs (rw)
udev on /dev type tmpfs (rw,relatime,size=10240k,mode=755)
/dev/sr0 on /livemnt/boot type iso9660 (ro,relatime,mode=0644)
/dev/loop0 on /livemnt/squashfs type squashfs (ro,relatime)
tmpfs on /livemnt/memory type tmpfs (rw,relatime)
none on / type aufs (rw,noatime,si=5bb6167003aefe61)
tmpfs on /livemnt/tftpmem type tmpfs (rw,relatime,size=524288k)
none on /tftpboot type aufs (rw,relatime,si=5bb6167003aeae61)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,size=1640680k,mode=755)
udev on /dev type devtmpfs (rw,nosuid,relatime,size=10240k,nr_inodes=2047722,mode=755)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
fusectl on /sys/fs/fuse/connections type fusectl (rw,nosuid,nodev,noexec,relatime)
efivarfs on /sys/firmware/efi/efivars type efivarfs (rw,nosuid,nodev,noexec,relatime)
openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-agent.sh,name=openrc)
cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
memory on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
devices on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
freezer on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
net_cls on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
blkio on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
perf_event on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event)
tmpfs on /tmp type tmpfs (rw)
/dev/sdb1 on /mnt/backup type ext4 (rw)

I got this error:

zsh: Input/output error: extundelete

Hmm.. could be a problem with your channellist.

Maybe it's including some parameters not necessary for the normal VDR distribution, but for the Reelbox.

I would recommend making a copy of your channellist and take one from channelpedia just for testing

Yep. This is the drive i installed today. It is not included in Snapraid.

Here we go

blkid

/dev/loop0: TYPE="squashfs"
/dev/sda1: UUID="be149662-abd5-4d5d-b532-14d091321812" TYPE="ext4" PARTUUID="000397bf-01"
/dev/sda5: UUID="5d31da78-38c9-48e7-8aa0-bfa5c4b18235" TYPE="swap" PARTUUID="000397bf-05"
/dev/sdb1: LABEL="Backup" UUID="c7692c8e-2a3e-4ac2-b954-29c71ac43df9" TYPE="ext4" PARTUUID="abbbbcb7-4831-4c62-b4ce-b8eefa757578"
/dev/sdc1: LABEL="DISK3" UUID="858099db-5680-44d7-8cd3-79134be2157c" TYPE="ext4" PARTUUID="571fd11d-2fe9-46a0-a45e-32bfd5a677ef"
/dev/sdd1: LABEL="DISK2" UUID="2f914808-85f6-4b9b-aee3-43cfad784960" TYPE="ext4" PARTUUID="e563015a-431e-488a-93ea-30960db9df19"
/dev/sde1: LABEL="DISK1" UUID="0722de2e-cf4b-4a63-aece-f01f502b7c27" TYPE="ext4" PARTUUID="da3e312c-be1c-42b3-bd40-810f5be6ce4b"
/dev/sdf1: LABEL="Parity1" UUID="a7f543ef-6a8f-41f9-ac83-942085c9bfca" TYPE="ext4" PARTUUID="c206d942-0953-4b93-bb1b-2239a8c42fe7"