Beiträge von bszabo

Zitat

Also I noticed, that under Storage->File Systems the "/srv/mergerfs/home_media_server" is not mounted. Could that be the underlying issue? I found this thread about this, could the solution there solve my problem as well? (I don't mind deleting the newly created files in the mergerfs location)

I actually tried the solution from the other tread and it worked perfectly. There is also a great tip there to hit the Install Docker button under OMV-extras if the file system was added after the initial docker install (which was in my case) which will add all mounts to the config file so docker will wait at startup until all file systems are mounted, and hopefully prevent this happening again in the future.

But thanks chente for the help anyway!

Zitat

You didn't mention anything in your first post about applications writing to that mergerfs pool

Sorry, I realized later that it's used and that's important. And yes it is used by apps in docker containers

Zitat

If you are not sure about any action or have any questions, please ask before doing so

So in OMV under

• Storage->mergerfs: I have a pool called "home_media_server"
• Storage->File Systems: I have the physical drives and a FUSE.MERGERFS type file system called "/srv/mergerfs/home_media_server"
• Storage->Shared Folders: I have a folder called "NAS_home" with relative path "NAS_home/" and absolute path "/srv/mergerfs/home_media_server/NAS_home"
• Services->SMB->Shares: I have a share based on NAS_home folder

My first issue is that the delete icon is greyed out if i select the "home_media_server" under Storage->mergerfs. But if I manage to remove and recreate the pool, then I'd need to edit the "NAS_home" shared folder to use the newly created FUSE.MERGERFS file system?

Also I noticed, that under Storage->File Systems the "/srv/mergerfs/home_media_server" is not mounted. Could that be the underlying issue? I found this thread about this, could the solution there solve my problem as well? (I don't mind deleting the newly created files in the mergerfs location)

So if I remove the pool and recreate the pool with the same drives and same name will all my files be "restored" and the other application will be able to use the mergerfs file system?

Some additional info, this is how my drives/folder structure looks (with some simplification) if I SSH into the server:

/srv/dev-disk-by-uuid-drive1
 |- MainFolder
 |   |- Folder1
 |   |   |- File1
 |   |   |- File2
 |   |- Folder2
 |       |- File3
/srv/dev-disk-by-uuid-drive2
 |- MainFolder
 |   |- Folder1
 |   |   |- File4
 |   |- Folder2
 |       |- File5
/srv/mergerfs
 |- MainFolder
 |   |- Folder1
 |   |   |- NewFile1
 |   |- Folder2
 |       |- NewFile2

So after I restarted, the folder structure recreated itself but the old files were not there and the applications that are using the mergerfs pool started creating files in this new /srv/mergerfs location.

I had a mergerfs pool set up with two drives which was working fine, but recently I had to restart my server a few times (during some of the restart one of the drive that is in the pool was not connected, while the other was). Now once I put everything back and started up the server for normal use, the mergerfs file system is empty. The data shouldn't be lost, since if I SSH into the server I can cd to both of my drives and the files that were there are still there, but if I look at the SMB that is based on the mergerfs file system or if I cd to the /srv/mergerfs folder in the console, it is empty.

Is there some way to fix this and make mergerfs "recognize" my files again?

Any settings that I should do differently so this won't happen in the future?

PS:

This is the output for sudo omv-showkey mergerfs

<mergerfs>
    <pools>
        <pool>
            <uuid>a2757897-6626-4937-8851-cbe9752e94cd</uuid>
            <name>home_media_server</name>
            <mntentref>524d71e1-11fb-46f2-b055-fb7df4ab7f09</mntentref>
            <paths>/srv/dev-disk-by-uuid-89dd386a-5910-4530-be02-9a7feb63280a:/srv/dev-disk-by-uuid-bbda4c49-079c-4ec0-9664-2831abc66b0f</paths>
            <createpolicy>epmfs</createpolicy>
            <minfreespace>4</minfreespace>
            <minfreespaceunit>G</minfreespaceunit>
            <options>defaults,allow_other,use_ino,cache.files=partial,dropcacheonclose=true,category.create=mfs</options>
        </pool>
    </pools>
</mergerfs>

Zitat von chente

Do not delete them, I have already seen this behavior on my server and I have not given it importance. They are probably temporary files.

Ok thanks!

(Maybe they are subsequent modification that haven't been applied and that's how omv tracks and allows to revert back changes)

I have an issue similar to this, and while I was looking into the possible solutions I noticed that in my /etc/openmediavault/ folder I have several config.xml file with additional suffixed numbers:

pi@raspberrypi:/etc/openmediavault $ ls
config.xml    config.xml.0001     config.xml.0002     config.xml.0003     config.xml.0004     php.ini

Are those valid files, or are they corrupted/unused files?

So basically, can I delete the ones that have `.000x` number suffix?

Ok, it seems like the issue was that omv didn't recognize the network interface automatically, so I had to add manually the interface under "System->Network->Interfaces" and after that it works fine.

I have docker and portainer (from omv-extras) installed on my omv and they are running my containers fine.

But I'm unable to update my images, I always get connection refused error:

Get "https://lscr.io/v2/": dial tcp: lookup lscr.io on [::1]:53: read udp [::1]:56187->[::1]:53: read: connection refused

Some googling suggest that it is some kind of DNS issue, but I'm not sure what is the problem. Is this error familiar to anyone or know what to do? Do I need to forward some port on my router or set up smething between the portainer and omv?

Note: BTW I'm also running wireguard and duckDNS from a container and accessing the server through VPN in case that has any effect.

I have OMV running with a storage drive mounted, file system created on it. This file system is also shared (SMB) and I also reference it in docker containers.

I'd like to extend the capacity of this file system by connecting another external drive to OMV. Is there a way to "add" the capacity of the new drive to the existing one?

I assume I have to create a pool with the two drives, but my question is

1. Is it possible to do it without disturbing my current settings in the shared folder and docker references? Or the only way to do it is to create a pooled file system and set up a the sharing and docker volumes again?
2. If I have to create a new pooled file system, will the data (and folder structure) on my current drive survive, or do I have to back up the data and restore it after the new file system is created?

Note: I don't need any redundancy in the pooled file system, it doesn't hold sensitive data.