Beiträge von threehappypenguins

    I also have an Odroid HC4 and it randomly reboots with certain commands. I also noticed that sudo systemctl status chronyd also gets the error:

    Code
    System clock wrong by 5964545.017708 seconds
    System clock was stepped by 5964545.017708 seconds

    If I restart the chronyd service, it gets rid of the error and I still get random reboots when executing some commands. If I reboot, the errors come back. I can't install ntp or systemd-timesyncd because it will automatically remove OMV. I tried installing them prior to OMV install, but the OMV install script removes them in order to have chrony.


    Currently, my system is completely unusable with OMV. I have bookworm with OMV 7. Fresh install. I have tried nuking it and installing fresh over and over again, with the same results.

    I just wanted to say that I'm also getting this message upon reboot or startup. I have an Odroid HC2 with Debian Bullseye and OMV 6. It's annoying because it just sits there for a few minutes and I can't ssh in or do anything until it finally moves past. It does this any time I reboot.

    I don't know, but it seems essential for postfix. It does not matter if it is empty, it only has to exist. I assume it will be populated at runtime.

    So I'm assuming that it's because of the error [ERROR ] stderr: /usr/lib/postfix/sbin/post-install: Error: /etc/postfix/postfix-files is not a file.?


    Why is creating the file not an optimal solution? How do I know what the "real problem" is?

    Could you please run ls -alh /etc/postfix/ and postthe output here?

    I want to add SSH keys for a user and every time I try to apply changes, I get this error:


    Code
    500 - Internal Server Error
    Failed to execute command 'export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin; export LANG=C.UTF-8; export LANGUAGE=; omv-salt deploy run --no-color postfix 2>&1' with exit code '1': odroidxu4: ---------- ID: configure_postfix_main Function: file.managed Name: /etc/postfix/main.cf Result: True Comment: File /etc/postfix/main.cf is in the correct state Started: 22:54:29.112181 Duration: 237.195 ms Changes: ---------- ID: configure_postfix_master Function: file.managed Name: /etc/postfix/master.cf Result: True Comment: File /etc/postfix/master.cf is in the correct state Started: 22:54:29.350043 Duration: 34.694 ms Changes: ---------- ID: configure_postfix_recipient_bcc Function: file.managed Name: /etc/postfix/recipient_bcc Result: True Comment: File /etc/postfix/recipient_bcc is in the correct state Started: 22:54:29.385321 Duration: 29.945 ms Changes: ---------- ID: run_postmap_recipient_bcc Function: cmd.run Name: postmap /etc/postfix/recipient_bcc Result: True Comment: State was not run because none of the onchanges reqs changed Started: 22:54:29.420407 Duration: 0.04 ms Changes: ---------- ID: configure_postfix_recipient_canonical Function: file.managed Name: /etc/postfix/recipient_canonical Result: True Comment: File /etc/postfix/...

    I do have postfix on the system, as I have inotifytools and have an email sent under certain circumstances. I had OMV 6 and tried updating to the latest (6.4), but that didn't make a difference. I tried removing my Shared Folders, unmounting the main drive (I have an Odroid HC2), and then I uninstalled OMV:


    Code
    sudo apt remove openmediavault openmediavault-flashmemory openmediavault-omvextrasorg openmediavault-sharerootfs openmediavault-keyring
    sudo rm /etc/apt/sources.list.d/openmediavault.list
    sudo apt update
    sudo apt upgrade

    Then I reinstalled OMV:

    Code
    sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

    I rebooted and then reinstalled OMV-extras:

    Code
    sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/packages/raw/master/install | sudo bash

    I noticed that I could use my old login to log into the OMV interface (it wasn't default despite it being a new install). I have not mounted the main drive yet (Debian Bullseye and OMV on a microSD in Odroid HC2). I saw that my user was still there, as if I never uninstalled OMV. I tried to add the SSH key and apply the changes, and got the same error.


    Short of nuking the whole thing and re-writing everything on the SD card, what can I do to fix this?

    MORE weird behaviour. I deleted the Shared Folders via GUI and unmounted again, then did the lazy umount of /dev/sda6 and listed directory contents of /srv. Showed the AppData and ServerFiles folders and no dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 directory. cd'd into AppData, cd'd back out of it and into /srv again, listed directory contents again, and this time AppData and ServerFiles were magically gone, and it started showing dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 directory. Checked for hidden files, and same thing. So I removed dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 directory while /dev/sda6 was unmounted, just to see what happens.


    Then I mounted /dev/sda6 again, did ls of /srv, and it showed both dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 and dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e as normal. cd'd into dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 and did ls, and showing the AppData and ServerFiles folder, along with dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e (not normal? because that dev-disk folder is /dev/sdb1). cd'd back to /srv and it's still not showing AppData and Server Files... for now.


    I then thought about the fact that /dev/sda2 was still showing in File Systems (where my OS is installed) because I had previously installed the sharerootfs plugin because I was having trouble getting /dev/sda6 to show (as explained in my other post linked in my OP here). But when I uninstalled omv via ssh, I had installed sharerootfs along with it there. However, upon reinstallation, though I did not install the sharerootfs plugin again (realized I don't need it), /dev/sda2 was still showing in the File Systems page in the GUI. I wondered if maybe this had anything to do with it, so I installed the sharerootfs plugin again, and then uninstalled it via the GUI, and now /dev/sda2 is no longer showing (as expected).


    So I decided to unmount /dev/sda6 again, and THIS TIME, when I went to mount it again, it showed (I didn't need to do the lazy umount command). So I mounted it without issues. The AppData and ServerFiles folders still weren't showing in the /srv folder, however, the dev-disk folder for /dev/sdb2 was still showing within the dev-disk folder for /dev/sda6.


    I'm hoping someone can explain what's going on, and if any of this is normal behaviour, and if I have anything to worry about.

    I had the exact same issue, however I didn't know what you meant that you had to "manually setup eth0 again." Finally figured out that I can go to Network > Interfaces, choose eth0, delete it, DON'T apply the changes, then create eth0 again, making sure to enable DHCP for ipv4 in the creation. Then I applied both changes (the deletion and creation), and that fixed the issue for me.

    Seems resolved for now. I manually removed (sudo rm -r) the AppData and ServerFiles folders that were directly in /srv while the /dev/sda6 partition was not mounted. Then I tried to mount /dev/sda6 again in the GUI via File Systems, and it did not show. So in ssh, I tried to manually unmount it, but sudo umount /dev/sda6 showed umount: /srv: target is busy. sudo lsof /dev/sda6 did not produce anything. The only thing to work was "lazy" umount, sudo umount -l /dev/sda6.


    Then in File Systems, /dev/sda6 showed again and I could mount it again without issues. I navigated (via ssh) to /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 and saw that AppData and ServerFiles were also gone from there. So in the OMV GUI, I created the same Shared Folders again, and they only showed in /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 and not directly in /srv like before.

    More strange behaviour. I deleted the Shared Drives via the OMV GUI from the /dev/sda6 SSD partition and they still showed in /srv and /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4. I then rebooted; still there. I then unmounted the /dev/sda6 partition via the OMV GUI (Storage > File Systems), and while /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 is gone, /srv/AppData and /srv/ServerFiles are still there.

    I was having issues mounting a file system, but I appeared to have resolved it by uninstalling and reinstalling OMV.


    But now that I have created some shared folders on the SSD that contains the OS (on a separate partition; /dev/sda2 has the OS and /dev/sda6 is the storage that I set as /srv), I have folders outside of /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4 AND the same folders inside of it (for example, /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4/AppData AND /srv/Appdata). Whatever I create in one AppData folder, it happens in the other. I checked to see if they were symlinked, but ls -l does not show they are. In the dev-disk folder, it also shows both dev-disk folders (I have another SSD that is /dev/sdb1) In /srv/dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4:


    Code
    total 56
    drwxrwsrwx 2 root users  4096 Jan 31 11:28 AppData
    drwxrwsrwx 2 root users  4096 Jan 31 11:29 ServerFiles
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.group
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.user
    drwxr-xr-x 2 root root   4096 Aug  7 10:25 dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4
    drwxr-xr-x 2 root root   4096 Aug  7 10:25 dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e
    drwx------ 2 root root  16384 Jan 30 20:35 lost+found
    drwxr-xr-x 3 root root   4096 Jan 30 20:57 pillar
    drwxr-xr-x 7 root root   4096 Jan 30 20:57 salt

    And in /srv:

    Code
    total 56
    drwxrwsrwx 2 root users  4096 Jan 31 11:28 AppData
    drwxrwsrwx 2 root users  4096 Jan 31 11:29 ServerFiles
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.group
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.user
    drwxr-xr-x 9 root root   4096 Jan 31 11:14 dev-disk-by-uuid-6919b6e7-2b51-4384-b2e6-67b8109762d4
    drwxr-xr-x 4 root root   4096 Jan 31 11:15 dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e
    drwx------ 2 root root  16384 Jan 30 20:35 lost+found
    drwxr-xr-x 3 root root   4096 Jan 30 20:57 pillar
    drwxr-xr-x 7 root root   4096 Jan 30 20:57 salt

    drwxrwsrwx is what is displayed; no l for symlink; just d for directory.


    The other disk (/srv/dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e) does not have the same behaviour. In /srv/dev-disk-by-uuid-e9fffc3c-2a02-4fdb-a79a-f7c684eb9f7e (/dev/sdb1, the other SSD) showing my Shared Folder Backup, as normal:

    Code
    total 36
    drwxrwsrwx 2 root users  4096 Jan 31 11:15 Backup
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.group
    -rw------- 1 root root   6144 Jan 30 22:32 aquota.user
    drwx------ 2 root root  16384 Jan 30 22:05 lost+found

    I also don't know why the dev-disk folders are showing Aug 7. I only started setting things up yesterday.

    I decided to nuke it:

    Code
    sudo apt remove openmediavault openmediavault-flashmemory openmediavault-omvextrasorg

    Then reinstalled:

    Code
    sudo wget -O - https://github.com/OpenMediaVault-Plugin-Developers/installScript/raw/master/install | sudo bash

    Then:

    Code
    sudo systemctl unmask openmediavault-engined.service
    sudo systemctl enable openmediavault-engined.service
    sudo systemctl start openmediavault-engined.service

    After that, I was able to log in the GUI, and then mount the paritions without issues.

    I have an Odroid HC4 with two 1 TB SSD drives. I used petitboot to installed Debian 11 (Bullseye), and partitioned /dev/sda (first SSD) to contain the OS (created /boot (primary 509.6 MB), / (primary 32 GB), swap (logical 999.3 MB), and /srv (logical 990.7 GB). I want the /srv partition to contain my shared drives that I will create with OMV. The 2nd SSD (/dev/sdb) will just be a backup drive that I will configure later.


    After I am done and I install OMV, when I go to Store > File Systems, and I go to create the mount, there is no sda6 available. Then I realize that I already created the partition, so I try to mount it. It's not showing there either. Then I realize that it must be mounted already, so in ssh in terminal, I sudo umount /dev/sda6. I then can see sda6 to be able to mount in File Systems. But when I apply, it throws the error:


    Code
    Can't Mount: 500 - Internal Server Error
    Failed to execute command 'export
    PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin;
    export LANG=C.UTF-8; export LANGUAGE=; omv-salt deploy run
    --no-color fstab 2>&1' with exit code '100': ERROR The state
    'fstab' does not exist

    I also noticed that when I create a partition on /dev/sdb on the OMV GUI, I get

    Code
    omv Warning: Partition table header claims that the size of partition table entries is 0 bytes, but this program supports only 128-byte entries.
    Adjusting accordingly, but partition table may be garbage.

    And when I try to mount sdb1, it throws the same error as when I try to mount /dev/sdb6.

    Another thing to consider if it's possible is to run a duckdns updater on your router. I do.

    Yes, I do that as well. But I have a separate server name for sftp transfer so that the camera/sound guy at my church can transfer videos to the church server that I host at my house, and this keeps things neat and tidy in case I move the server to another location.

    Okay, I have it working. I ended up choosing the tag arm32v7-version-4c2a0989 and it worked fine. For some reason, using the latest tag won't work for me. I have armv7 (Odroid HC2), but I'm not sure how to specify the digest with the latest tag. I don't really understand how the docker pulls work, and whether it detects my system and pulls the linux/arm/v7 digest.

    All I can say is that the duckdns client instance is not working on that machine for some reason. Try deleting the container and build it again.

    I already tried that. It was the first thing I did. So just now, I deleted everything and downloaded an old version of duckdns docker (it's from linuxserver). I used the tag arm32v7-44472b80-ls38. I tried to find the same one that is on the working machine, but I can't find it by its tag. So I used command line and tried to download by digest:

    Code
    docker pull sha256:725dedce8fb60cb5bf9bc0262bc24129d717457baf3bbd4a12b4fb390d7f6dc7

    It downloads it, but then on the docker GUI, it doesn't show the repository name or tag, and I can't run an image with it. So I don't think I'm doing it right. So anyways, I used the tag arm32v7-44472b80-ls38 instead (not the one I have on the working machine), and now I get this error in the logs (with my duckdns token for "token-number-token-number-token":


    If you could help me get the same image as what's on the working machine, perhaps it will work for the non-working machine.

    Did you use your duckdns domain name or did you put domainame in the command?

    Oh hahaha. I literally put "domainame." I was thinking it was a special command. LOL. Ok, here are the results, but with my actual domain name (edited out to be "domainame," and the IP address showing is edited to be "12.3.456.7" but the original was the old IP):

    And the working machine (edited to be "domainame2" and IP address is correct but I edited to be 89.10.234.5):