Posts by HannesJo

As it says, still in use. Have you unmounted the drive?

Quote from phillipzan

I hate SSH I can never remember commands

Perhaps not the best idea to run a server then. You can just make a list of commonly used commands. It is not that many. And no one here in the forum will be able to help as long as you don't provide necessary information.

So as gderf already said, your file obviously has a permission problem. You've got to solve that.

The easy, quick and dirty way: In the OMV GUI, go to sharedfolders, select the corresponding sharedfolder and click ACL. In the bottom area "extra options", make sure everyone has Read/Write/Execute access. Select "Replace" and "Recursive" and apply. You should be able to delete the file now.

A better way: SSH into your omv server, navigate to the files and inspect their permissions. Correct them / Delete your mkv and check if makemkv is now setting correct file permissions.

I use gocryptfs

I would say just stick with boxcryptor.

Ok also der Balance Befehl ist soweit erstmal nicht sehr kritisch. Den kannst du einfach mal probieren. Ansonsten sei ohne Backup echt vorsichtig. Ein RAID schützt dich nicht vor Datenverlust. Es ist nur dazu da dass dein Server ausfallsicher ist. Also bei einer defekten Festplatte funktioniert er von außen gesehen normal weiter und bleibt online. Aber wenn Daten gelöscht werden oder du einen Fehler in den Einstellungen machst hilft nur ein Backup. Das verstehen viele falsch.

Das nächste Ding ist BTRFS. Ich benutze das auch. Es hat viele Vorteile. Aber OMV kann damit nicht so gut umgehen. Deswegen steuert man es eigentlich komplett über die Konsole. Dadurch dass du es über OMV eingerichtet hast bekommst du ein paar Nachteile. Zum Beispiel funktioniert das checksumming soweit ich weiß nicht mehr. Kannst du mal googeln (BTRFS mdadm raid).

Am besten lernst du und vermeidest Server off Zeiten indem du Änderungen wie jetzt am Raid in einer virtuellen Maschine testest. Dort hättest du z. B. erst testen können wie die Erweiterung vom Raid funktioniert ohne dass Daten verloren gehen können. Gerade wenn man kein Backup hat. Ich weiß ja nicht was für Daten das sind aber die sind oft ja das wertvollste am ganzen Server.

Das mit den geänderten Buchstaben ist nicht ungewöhnlich. Die werden nicht wie bei Windows fest vergeben sondern einfach in der Reihenfolge in der die Geräte erkannt werden. Wirklich eindeutig ist nur die uuid. Es kann aber tatsächlich vorkommen dass es Probleme gibt wenn Programme über den Buchstaben gehen wollen. Dann muss man sie ändern sodass sie über die uuid gehen.

Ok also das Ding ist dass BTRFS eigentlich selbst das RAID verwaltet. Die OMV GUI kann das aber nicht. Die benutzt auch für BTRFS mdadm. Das ist zumindest nicht optimal, sollte aber funktionieren. Erstmal das Wichtigste vorweg: Hast du ein Backup deiner Daten?

Wenn nein mach erstmal das Backup. Wenn ja versuch es mal mit

btrfs balance start -v /srv/dev-disk-by-label-<your btrfs pool>/

Verstehe ich das richtig dass du ein BTRFS Raid über die Weboberfläche angelegt hast?

I agree that storing dashboard settings locally only can be annoying. But it has some pro arguments also and I think it’s the same with omv5 right?

Quote from votdev

By the way, i improved the CSS code a little bit, now no background related transformations are done anymore.

Have you been able to measure any actual performance improvement? That would be sth new to me.

Quote from Zoki

so we all miss reading your post.

Yeah, perhaps I expressed it badly.

Quote from Zoki

If you know how to solve it, why not provide a PR?

WTF? I literally explained to the TO why there is nothing to solve. Why OMV code is fine.

Now you tell me to send a PR?! votdev and mi-hol even like it?

Quote from alexxcons

Possibly your article already points at the problem in the omv code ... probably better to dont put an animation on the background-image, but rather put the image into some div, and do the animation there to prevent excessive repaints.

Dude, look at the code. The css property background-image is not being animated here. The image is animated using the property transform. votdev has literally applied all the stuff that is mentioned to avoid performance issues. How would you not get that? You are on the wrong track. You are totally confused. Animating a background image does not necessarily mean animating the css property background-image...

Quote

So you want to make hardware accel a requirement for using the omv-webgui ?

No, I don't wanna make any requirements. I just try to inform you about the very basics of css animations and their requirements. You can discuss that with votdev. He writes this software in his free-time and you are free to use it or to use something else if you don't like it. Or just fork it and make your changes

The animation is, as votedev already mentioned, simple css animation. On css animations there are some basic rules what should be avoided in order to prevent performance issues and what is ok. Checking the code in question you can find only animations are being used that browsers can execute very cheaply (position transform, scale transform, opacity) as long as there is hardware-acceleration. I was just wondering if this may be about using 10yo hardware? Maybe, but: Here you can find an article from 2013 where these css animation types are already stated to enable smooth high performance animations. So you're not dealing with the latest state-of-the-art-stuff here.

I think your old hardware or some misconfiguration could be the issue. But this is clearly not a bug. Maybe some browser extension like this one can help you.

Quote from Zoki

Unfortunately in german: https://www.thomas-krenn.com/d…hing_mit_SSDs_einrichten#

?

I think you can but it is not OMV related. Just do some research on caching on Debian distro. But as far as I know, proper caching is not an easy thing.

Oh yeah I got your thread wrong. Sorry for that.

There is no difference between OMV 5 and 6. Actually you don't even should stick to OMV. You should simply get familiar with Unix / Linux permissions. OMV is using just that.

I see. Gonna keep an eye on it. Thanks!

I have just updated the setting so the output of timedatectl changed to synchronized but still NTP service inactive.

> timedatectl
               Local time: Mon 2022-01-10 14:17:49 CET
           Universal time: Mon 2022-01-10 13:17:49 UTC
                 RTC time: Mon 2022-01-10 13:17:49
                Time zone: Europe/Berlin (CET, +0100)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

> systemctl status chrony
● chrony.service - chrony, an NTP client/server
   Loaded: loaded (/lib/systemd/system/chrony.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-01-10 14:10:53 CET; 7min ago
     Docs: man:chronyd(8)
           man:chronyc(1)
           man:chrony.conf(5)
 Main PID: 8104 (chronyd)
    Tasks: 2 (limit: 4915)
   Memory: 1.0M
   CGroup: /system.slice/chrony.service
           ├─8104 /usr/sbin/chronyd -F -1
           └─8105 /usr/sbin/chronyd -F -1

Jan 10 14:10:53 NAS systemd[1]: Starting chrony, an NTP client/server...
Jan 10 14:10:53 NAS chronyd[8104]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHA
Jan 10 14:10:53 NAS chronyd[8104]: Frequency 2.684 +/- 0.450 ppm read from /var/lib/chrony/chrony.drift
Jan 10 14:10:53 NAS chronyd[8104]: Loaded seccomp filter
Jan 10 14:10:53 NAS systemd[1]: Started chrony, an NTP client/server.
Jan 10 14:10:57 NAS chronyd[8104]: Selected source 217.144.138.234
Jan 10 14:10:57 NAS chronyd[8104]: System clock wrong by 5.474326 seconds, adjustment started
Jan 10 14:11:03 NAS chronyd[8104]: System clock was stepped by 5.474326 seconds

> journalctl -u chrony
-- Logs begin at Thu 2022-01-06 00:52:18 CET, end at Mon 2022-01-10 14:18:12 CET. --
Jan 10 14:10:53 NAS systemd[1]: Starting chrony, an NTP client/server...
Jan 10 14:10:53 NAS chronyd[8104]: chronyd version 3.4 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +SECHA
Jan 10 14:10:53 NAS chronyd[8104]: Frequency 2.684 +/- 0.450 ppm read from /var/lib/chrony/chrony.drift
Jan 10 14:10:53 NAS chronyd[8104]: Loaded seccomp filter
Jan 10 14:10:53 NAS systemd[1]: Started chrony, an NTP client/server.
Jan 10 14:10:57 NAS chronyd[8104]: Selected source 217.144.138.234
Jan 10 14:10:57 NAS chronyd[8104]: System clock wrong by 5.474326 seconds, adjustment started
Jan 10 14:11:03 NAS chronyd[8104]: System clock was stepped by 5.474326 seconds