Beiträge von m4tt0

Im Prinzip schon. Du musst die in OMV nur sauber "abmelden" und hinterher wieder "anmelden".

Abmelden beinhaltet:

- Alle Referenzen auf die defekten Platten deaktivieren bzw. löschen (z.B. rsync jobs, SMB Freigaben, etc)

- Dann aushängen (unmounten). Wenn Du beim Schritt vorher was vergessen hast, geht das nicht.

- Dann runterfahren und Platte ausbauen

- Woanders klonen, und alles wieder rückwärts.

Du kannst das aber auch unter OMV machen, wenn Du noch einen Festplattenslot hast, z.B.:

- Neue Platte rein und temporär einhängen

- rsync job einrichten, um alles rüberzuschaufeln

- Alte Platte aushängen und ausbauen (s.o.)

- Neue Platte wie die alte konfigurieren.

Btw, I love your signature: "OMV 3.0.XX Erasmus always up to date."... *LOL*

Yes, I would...

1. Remove all references to the RAID first, i.e. SMB shares, shared folders, rsync jobs, whatever points at it...
2. Dissolve the RAID (if you haven't done step 1 or you forgot to remove pointers, you may struggle here)
3. Properly wipe all individual discs to avoid data theft (if you are concerned about that)
4. Shutdown the computer
5. Remove the old drives, install the new ones

...and take it from there.

Can confirm. Using SPICE and virt-viewer, everything works as expected. Many thanks chente and ryecoaaron. Gee, what a journey!

P.S.: And for those trying and wondering how to run the virt-viewer SPICE client on Windows: Nooooo, there is no virt-viewer app (that would obviously be too simple). "Remote Viewer" is the name of the app you are looking for. Not sure if you want to chente, but may be worthwhile adding to your very nice guide, too...

OK. Thanks. I've manually changed the "/etc/default/keyboard" file to switch to a US keyboard layout. After reboot, the hyphen is working. Not ideal, but at least manageable.

If anybody has a better solution, please let me know. Thanks again.

ryecoaaron Thanks for looking into this, but is the keyboard mapping actually working for you? If so, what is your layout and configuration, please? I'd have no issue using a US or French layout or what not on my German keyboard, but I do have an issue with not being able to produce hyphens at all, because key presses don't produce anything or every other one produces "Ö"s...

I just tried to install a Debian VM using the KVM plugin. Setup itself went fine and I was able to get it up and running and connect to it with a VNC client. My only problem is that it is almost unuseable, as the keyboard layout is completely messed up.

I installed Debian inside of the VM using German keyboard layout. The VNC client runs on a Win 10 laptop with a German keyboard layout, too. I tried tightVNC, turboVNC and VNC Viewer. Same problem everywhere. I tried to run "dpkg-reconfigure" commands to change the keyboard layout within the Debian VM, but no matter what I press, there is no hyphen anywhere, so I cannot execute the command. It's crazy.

Have you ever encountered similar problems? And if so, how have you solved them? Any advice appreciated...

OK, I kept receiving those notifications, but I've finally managed to get rid of them.

The short version: votdev was right. It was a configuration problem.

The longer version;

- I've started tracking when the connection failures started to occur and realized they in fact did occur regularly, every second Friday at pretty much the same time in the middle of the night.

- I then started checking the logs and realized that immediately prior to the issue occuring, I had rsync jobs failing.

- Looking into them, I quickly realized what was wrong: I exchanged my server some months ago and demoted the former server to a backup medium. At the same time I changed the old server IP and assigned the old server IP to the new server. I did not change the rsync job though.

- In effect, my new OMV server tried to rsync to itself, with login information for a user that did not exist and while no rsync server was running (that just runs on the old server).

- I've corrected the configuration and restored the standard monit configuration more than three weeks ago.

- No problems since and given the above, I'd be surprised they'd return.

That's it! Welcome...

OK, I assume that is how you labeled the USB drive you wanted to record to, i.e. "Datensicherung" is the label of the drive, no?

If that's the case, your recording folder should be in there.

If you go into your OMV web-interface, to Access Mgmt -> shared folders, which entries do you see?

Your path should begin with /srv/...

Take a look there and try again...

Depends on your setup:

- Do you use a TVH docker container or is it installed natively on your OMV?

- Have you created a shared folder for your recordings?

- If you use docker, how are folders mapped?

- What are the Filesystem settings in the TVH Web-interface (c.f. Configuration -> Recording -> Digital Video Recorder Profiles: right hand side)?

+1

And here...

Zitat von cubemin

...(I probably should submit this to Github or something)...

Yep. Please do. It seems you've collected enough evidence for votdev to consider...

Thanks, ptruman. I've changed the "disabling teamviewer" config entry to "false", reran the omv-salt commands above, and can confirm that the teamviewer repo works correctly again.

Most certainly. Did it again today. But I remember that the updates this week contained an update of OMV itself. Maybe that's why. I ran those manually (using apt-get) because of the source-list / teamviewer problems...

cubemin : Unfortunately this did not work either. Ran into an email wall again yesterday. Undoing the changes.

EDIT: Too quick, too early: Trying to "undo" the changes, I saw that they had been overwritten by the original values. I ran updates earlier this week. That's probably why. Changed it again and will continue testing...

Sorry for the noise!

Thanks, cubemin. Just copied your approach. You've got a second tester...

Never thought about it much. I just find the setup practical. All files are in shared folders as they are not only accessed by docker containers, but also via SMB, etc. And storing all Docker Container Files in Appdata ensures they are all in one place, I can access and edit them via SMB, too, they are regularly backed up as part of my file server backup solution, and it gives me "independence" from the OS. If, for instance, my server or server OS breaks down, I can easily setup a new system with docker, restore all files, including the docker configurations and I'm up and running without much hassle. I could even change the OS, or (one day) upload everything into some virtualized cloud server. It would still work.

But there are many roads to Rome, and I don't think there is any "right or wrong" here. Just personal preference.

I've got no clue whether my setup is "best practice", but it grew over time and has been very useable since several years.

Here my shared folder structure:

For what it's worth. Hope this helps...