Posts by burnbasket

    Thank you for sharing!

    I also use Dolphin + KDE on most of the clients.
    No FTP, however, only CIFS/SMB and SSHFS (fish://...)

    Can you write to these partitions locally from the commandline on the OMV machine?

    E.g:

    Code
    touch /path/to/partition/test.file
    ls -lhA /path/to/partition/test.file
    rm /path/to/partition/test.file

    The first command creates an (empty) file with the name "test.file" on the partition.
    The second command shows the file.
    The third command deletes the file.

    I was completely wrong.

    This is the correct thread:

    Hi Richard, sorry for responding in English, but my French is atrocious ;)

    Could you post the complete error message?

    The parts up to the cut appear to have worked.


    For a first guess at approaching this: The email address contains no spaces and only one "@" , right?

    Non-ASCII characters might be a problem, because some can be represented as combining diacritical marks, e.g grave (´), acute (`), circumflex (ˆ), not a single combined character, e.g. é, è, ê in ISO 10646. These diacritical marks can look like non-word characters to some parsers.

    I don't recall which Debian install I originally used, but it is quite ancient. IIRC I did my last "full" OMV install with OMV6. Update OMV6 to OMV7 worked, now so did update OMV7 to OMV8.

    I looked over the Debian install procedure today, and I'm pretty sure I deselected everything in the install options, including "Standard System Utilities", back then.
    At the time I thought a server should only have the absolute minimum of preinstalled packages.

    Now I'm more relaxed with 50MB additional space requirement :)

    Everything works perfectly on OMV, it’s just that there are no updates.

    I don’t want to reinstall everything because that would mean completely reinstalling my Dockers, etc., and it would take me far too much time.

    I completely get that.

    There is one more possibility to consider: The "lack of updates" might be a perceptual misconception.

    Debian trixie went from "testing" to "stable" on 2025-08-09.

    Updates to "testing" are very frequent, almost daily. Updates to "stable" happen maybe once a month, sometimes even less than that.

    You might be getting updates just fine, but they are lot farther apart than you got used to using a Debian "testing" release.

    Are you sure this URL you used still exists?

    https://deb.nodesource.com/node_14.x/dists/bullseye


    Both node14 and Debian Bullseye aren't super new.

    Debian Bullseye was released 2021-08-18 with End-of-Life 2024-08-14.


    I have no idea about the support cycles in node.js, but the website

    https://deb.nodesource.com

    announces only one single (major) version, 22.x


    It's possible you would need to adapt the node.js URL to a more recent version.

    The system is reporting as debian 13 already. I would not keep using it this way because any update could break it.


    omv-release-upgrade may not work since it isn't expecting the system to be on debian 13 already.


    In my opinion, this system is past the fix point.

    The system is reporting as debian 13 already. I would not keep using it this way because any update could break it.


    I agree. Don't do any updates in this state.


    omv-release-upgrade may not work since it isn't expecting the system to be on debian 13 already.


    I agree, this is a suboptimal starting point. morganplancot: You've made your backups, right?


    In my opinion, this system is past the fix point.


    OMV 7 seems to be pretty resilient still working on Debian 13 for Morgan. They can still nuke it, if omv-release-upgrade fails.

    If it were my system, I'd give it a shot with omv-release-upgrade.

    You have both "bookworm" (Debian 12) and "trixie" (Debian 13) active repos in your sources. By default, Debian will select the newest (="trixie") versions. OMV 7 defaults to Debian 12 (bookworm) unless I'm mistaken.

    This might be the reason you don't get update suggestions on the GUI.

    If your system works correctly, I wouldn't touch it, if I were you, until you omv-release-upgrade to OMV 8.
    Mixed newer and older release packages are almost certain to break your system.


    I would suggest to keep it the way it is until OMV 8 is stable, then omv-release-upgrade.

    As far as I observed the omv-release-upgrade rewrites /etc/apt/sources.list and you'll be fine.


    Just in case you aren't scared yet, here are some options you might want to explore:


    Do you happen to have either of these?

    /etc/apt/preferences

    /etc/apt/preferences.d/

    (that is not /etc/apt/preferences.d/omvextras.pref or /etc/apt/preferences.d/openmediavault-local.pref, these are curated by OMV)


    If you do, they determine the priority of the selections for "apt update" and "apt upgrade".


    Generally, if installed packages already are a newer version (e.g. from a newer repo) than the default repo, they won't be suggested as updates.

    But you can change their priority, if you choose. Here is one example from a system that is not OMV:


    cat /etc/apt/preferences.d/trixieAndBookworm

    Code
    Package: *
    Pin: release a=bookworm
    Pin-Priority: 990
    
    
    Package: *
    Pin: release a=trixie


    In this case, the higher PIN-Priority 990 supercedes the default PIN-Priority (which is 500).

    As I said before, don't use this unless something already is unfixably broken.

    I am wondering why nftables is not installed on your system because this is the standard package on Debian since v10. What root OS are you using or how do you have installed OMV7 previously?


    You can install the missing package by running apt-get install nftables as root in the CLI.

    I don't recall which Debian install I originally used, but it is quite ancient. IIRC I did my last "full" OMV install with OMV6. Update OMV6 to OMV7 worked, now so did update OMV7 to OMV8.

    I should have seen this sooner:


    Code
    Dec 18 21:14:37 omv podman[6511]: Error: starting container 1d8d20e9d7c05aabe087cc09751152bdaed8355a7bcefb49e513574426b84a9f: netavark: nftables error: unable to execute nft: No such file or directory (os error 2)
    Dec 18 21:14:37 omv systemd[1]: pod-filebrowser.service: Control process exited, code=exited, status=125/n/a


    I didn't manually install a firewall on the OMV host system. Would I need to install the system requirements for nft?

    Upgrade OMV 7 to OMV 8: "filebrowser" start fails (otherwise painless and quick)


    I just upgraded a freshly updated OMV 7 ("apt update && apt upgrade") to OMV 8 with "sudo omv-release-upgrade".

    It was fast and required no manual interventions, but the GUI wants me to update "Pending configuration changes" (cpupower, filebrowser, monit, nginx, phpfpm).


    This step fails:

    Manual restarts also fail:

    sudo systemctl stop pod-filebrowser.service

    sudo systemctl start pod-filebrowser.service

    Job for pod-filebrowser.service failed because the control process exited with error code.

    See "systemctl status pod-filebrowser.service" and "journalctl -xeu pod-filebrowser.service" for details.


    sudo systemctl status pod-filebrowser.service



    sudo journalctl -xeu pod-filebrowser.service



    The filesystem specified in

    /etc/systemd/system/container-filebrowser-app.service

    (RequiresMountsFor="/srv/dev-disk-by-label-btrfsData00/") is mounted and accessible, SMB access also works.

    Hi

    What is 1Go? : 956.00 MiB

    Intel Atom? Which one? Something like an N170 processor? :Intel(R) Atom(TM) CPU D425 @ 1.80GHz

    I mainly use it as a file server and it plays its role well with a transfer speed greater than 100Mb/s with very low consumption.

    It appears you're running the "system FS" ("/") from a USB drive. This can work, if it only does "system" stuff. Since none of the other partitions are mounted, I'm guessing the copy job you're trying to run also uses this USB drive as the source or target? If that happens to be the case, please check if your USB drive isn't too I/O limited to do the job:


    Code
    lsusb -v


    If this drive runs at 480MB/s (USB 2 speed), the transfer on a 1GB/s (=1024MB/s) network card could saturate the source drive, which in this case is also the system drive. Unhappiness is virtually guaranteed, if this assumption is true.

    You can verify if my assumption is correct super easily: Try a transfer from a different drive. Ideally you could use one of the Toshibas for testing? For convenience, you can try another USB drive connected to another USB port as a data source, too.

    BTRFS works "reasonably" well but known issues are not being addressed and they haven't been for years. The project is stagnating. I'm of the belief that's where it will stay until another group picks it up, or maybe forks it, and begins to roll the ball again. In the bottom line, I think it needs a fresh team.

    I dislike to have to agree with you (not because you are you). Because you might be right. Somebody should do something.


    Like grandma said: If you want to stop the car, trust in God’s plan AND step on the brake.


    I'm practically useless with C code, but I'll take a look anyway. If the "volume close to full" lines jump up and down and scream at me, I will make an effort to point them out. Don't hold your breath. ;)

    While any admin home users, etc., should be aware of the filled state of their storage, I'm curious about what happened when BTRFS was over allocated. What was the ungraceful about it?

    Different scenario (not OMV, system + data same FS), no important data, my own fault and >5y ago.


    I filled an older PC (bad setup, root + home same FS) on a (largish) file transfer to home.


    It was a no UEFI system, I hadn't provided separate system disks (one disk held the MBR).


    On "bursting" ;) failed to read-only (which in retrospect could be called a "graceful" fail).


    The system still worked, within the limitations of a read-only root+home FS.


    I didn't manage to add an additional small disk to the filesystem from a "Debian Live" USB boot at the time (IIRC the btrfs tooling wasn't there).

    But I DIDN'T try hard. Anything longer than taking the backup from the (readable) filesystem would have been a waste of time. The hardware was (even back then) garbage.