Do you have WriteCache running? I had a similar problem coming from some code changes in the last weeks. If so, then try adding these lines into the writecache config as recommended by ryecoaaron. The "rrdcached = stopstart" is probably the important one.
Posts by erbsenzaehler
-
-
I restarted the NAS to make sure data is coming in for CPU etc., then I added the parameters to Write Cache settings and performed the flush via UI. Data is coming in afterwards and rrdcached is still running. That might be the solution. Thanks!
(Gemini had the same idea after I fed it the last two meaningful changes on the writecache script. You were faster and I trust people with knowledge more then AI and me prompting without too much knowledge. Shxt in, shxt out.)
-
I have similar problems since the last update I ran. The graphs in "Performance Statistics" are all visable on the UI but there is no data in it. Rebooting worked partially.
The drop in data seems to start at the time the daily flush is active in my settings on all the 3 occasions.
In Logs->Messages there is a lot of these messages
monit[822]: 'rrdcached' start: '/bin/systemctl start rrdcached'
monit[822]: 'rrdcached' trying to restart
Fiddling with Gemini told me the following:
QuoteRoot Cause: omv-mkrrdgraph was throwing ERROR: Unable to connect to rrdcached: Connection refused. The UNIX socket (/run/rrdcached.sock) had broken permissions or failed to initialize properly after the system update, causing collectd and monit to fail communicating with rrdcached.
and permisssions seems to be wrong according to Gemini.
Quoteroot@nas-julian:~# ls -ld /var/lib/rrdcached/
drwxr-xr-x 1 root root 4096 Sep 9 03:45 /var/lib/rrdcached/
-
Do you have two step verification enabled for your Google Account? It seems that this is also a requirement for using app password (written here).
-
Ja danke für den Hinweis, aber was soll das bringen?
Wenn ich das richtig verstanden habe ist das ein Fix wenn man von einer Version 7 auf 8 updatet hat, das habe ich meines Wissens nach nichtDas ist die Erklärung zum Beitrag von Ryecoaaron. Welchen Zustand dein System hat, weiß man ja nicht vorher.
Ich bin kein Linux Experte oder sonstiges großes mit Linux.
Was wird dir denn angezeigt, wenn du omv-upgrade als root ausführst?
-
PS: Bitte so erklären das auch ein Anfänger es versteht
Hier schreiben recht viele unter deinen Thread und haben eine anderes Problem als du. Du selbst wird wahrscheinlich auch in das Problem laufen, aber eins nach dem anderen.
Via SSH logge dich als root in deine Maschine ein. Dann diesen Befehl ausführenCodewget -O - https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/installScript/master/fix7to8upgrade | bashDas ist das fix7to8upgrade Skript, von dem ryecoaaron geschrieben hat. Er ist der Autor des Scriptes.
-
Just do as the document says. That second command is different from the first.
first: "preinstall"
second: "install"
-
Pretty sure, that you copied the command somehow wrong and the three dots shouldn't be there. Try again with the proper command.
Did clear your browser cache (which one is it?)? Open the website of your OMV machine, then press CTRL+F5 and/or CTRL+SHIFT+R. -
Try refreshing your Browser.
QuoteProblem #1: Web interface has missing fields and/or items showing that have been uninstalled and/or something just isn't working right.
Solution #1: Clear your browser cache or try ctrl-shift-R. -
It is not "somewhere else" but this thread and you don't get rubbished but corrected in a very straightforward manner because the statement is absurdly false. What you write is not in the document that people linked for you to work through. You are using the old document for OMV7 and not OMV8. Please just follow the link that people sent you multiple times and for your first install do what is being written. You will get a functioning system! The guides are brilliant and easy to follow.
Quote -
First answer in this thread was already a link to omv-extras and many more did so. I don't get why only now it is being considered...
-
OMV 8 is currently the only supported version of Openmediavault. OMV 8 runs on Debian Trixie (and Raspberry PI OS on RPI)!
Two sources that you can trust in that order:
- openmediavault.org with the documentation and this forum. This is the official site and forum of the developer!
- omv-extras.org with the extra plugins and their tutorials.
Read the install guide in the official documentation and then head over to omv-extras with New User Guide and Installing OMV8 on a Raspberry PI. The omv-extras guides take your hand and will guide you to a working system.
-
votdev already told you where to get it in post #3. https://docs.openmediavault.or…x/installation/index.html is the official doc and tells you how to do the install and where to download. Choose "Dedicated drive". Read warning text carefully.
omv-extras is another source of a well explained install "tutorial". https://wiki.omv-extras.org/doku.php?id=omv8:new_user_guide basically walks you through the same steps as official doc with some extra info that might be useful.
As a Linux and NAS/OMV beginner, I feel these two sites in that order – together with this forum – are the only sources that I trust enough to actually follow.
-
I asked an AI about this and the reason for the different behavior seems to be that WireGuard Easy is doing NAT. transmission-openvpn has the parameter LOCAL_NETWORK. Adding the ip range of the wireguard network from the plugin to it would probably make them behave the same.
-
Netzwerk -> Schnittstellen -> Netzwerkkarte auswählen und bearbeiten -> (ganz unten) DNS Server
-
Check out this post. Someone had a similar problem and found a solution.
-
Work your way through the omv-extras.org documents and try to stick somewhat close to them and read them thoroughly. You will get to docker_in_omvand that has Jellyfin Docker as example and includes reference to what to put for Intel Quick Sync. If that doesn't work directly you need to look in the Jellyfin documentation.
-
Under /srv/dev-disk-by-uuid-35a47e11-1aa8-4377-95c9-152c61c299e8/Data/documents
drwxr-sr-x+ 1 root root 0 Mar 5 21:52 sync_data1
drwxr-sr-x+ 1 root root 0 Mar 5 21:52 sync_data2
Those "sync_data" dirs need to acessible by appuser. They are not. That's why I had them owned by root with group users while creating them in the UI. Either users group needs to be able to write to it or appuser directly.
If no other user besides appuser needs to work with them, you can create the dir with appuser owner and dont care about the group. If you want other users on the NAS itself to be able to have access, you need to have the users group with write previleges and you need to set the UMASK environment variable.
In short: What you did now is somewhat correct. Would have been easier to start directly with those dirs having owner appuser or the group users. -
Sorry. I got no idea. When I followed the tutorial step by step it worked fine. Did you change anything on the settings of the compose plugin? You can and should try to follow exactly the tutorial to see if that helps. Start without symlinks etc. Then compare your intended setup with that what's working - compare permissions etc.
Here are my settings. They are using OMV8 style of variable replacement:
Code: yaml
Display More--- services: syncthing: image: lscr.io/linuxserver/syncthing:latest container_name: syncthing hostname: syncthing #optional environment: - PUID=${{ uid:"appuser" }} - PGID=${{ gid:"users" }} - TZ=${{ tz }} - UMASK=002 volumes: - ${{ sf:"docker_appdata" }}/syncthing/config:/config - ${{ sf:"syncthing" }}:/data1 # - /path/to/data2:/data2 ports: - 8384:8384 - 22000:22000/tcp - 22000:22000/udp - 21027:21027/udp restart: unless-stopped"syncthing" shared folder permissions: owner:root, group:users - rwxrwxr-x (could probably change the owner to appuser or some other user on the nas as well)
-
Did you try deleting all files and starting from scratch again after switching to appuser:users? In my setup (similar to yours without symlinks) the dir mapped to /data1 is owned by root:users with drwxrwsr-x+ and I don't get any problems in docker log.
