Just wanted to say had the same but with new versions of the packages, running the cmd rycoaaron posted have cleared them.
I have a drive reporting every now and again it can't read the smart data not sure if I should be worried but just incase I was going to look at getting a cold spare 3tb drive in just incase, but I'm abit out of the loop what are good drives for a server atm anyone got any recommendations it use to be always WD red but heard they had some bad ones, the current ones are Hitachi ones I got back in 2012 with the hp n40l microserver which have moved over to the Dell t430 server.
yes, do this:
In the thread I linked ryecoaaron gives the command to edit a systemd service file by creating an override file. And the first post proposes a modification for the delayed start of docker.
So I though this is what you had in mind.
Cheers will have a look and give it a try.
Typically when this happens, its because the docker service is starting before the drive with your config (or data) is mounted... so basically docker detects this as nothing being there. Very common issue when people have their config files on a merged filesystem.
Not sure why your backup drive would cause this. Putting them on another drive (or a drive that isn't external) can fix this. An easy way to verify this is your problem, simply hook your external up, boot the server, and assuming docker starts "empty", simply SSH your server and run the command
systemctl restart docker
Once docker is completely restarted, you should have full access to your containers. A lot of users have taken to setting up scripts, etc.. that just restarts docker 30sec after a boot (as the poster above did) and that would work as well so long as you're not the type to sit with a stop watch to see how long it takes your server to be up 100%
is the official fix. As my disks are internal to the Dell server I run connected to the backplane of the T430 but the server just starts faster then what the filesystem does I thought I saw one of the other mods mention a system config file that could be edited to fix it but can't find the thread now.
I have the same issue, due to the file system taking longer to mount then docker starting on startup. I'm trying to find the correct way to delay the docker startup to give the filesystem chance to load first.
There is no upgrade path and I need the system running (passwords in nextcloud, sync in firefox, emby media server).
Are these services not running in docker if so just backup the config folders for relinking for when you reinstall to omv 5
I confirm also on my side, no more erratic reboot with the latest kernel (5.7).
I guess we can now close this thread, as this is hopefully fixed
Guess I'll have to switch my pis back to NFS then lol
Good point, no this is on the latest OMV 5.x while copying any file larger than ~100MB. Since almost all files I'm transferring are at least that size, this happens non-stop and the syslog is 400+ pages after just a day.
I'm not sure which driver was used/selected in OMV 1.5 on Debian 7, but it didn't have this problem.
Are you running the latest kernal I've had an issue with NFS with kernal 126.96.36.199 as have some others but apprently 188.8.131.52 fixes it the other option was downgrading can do this with the omvextras
Turns out this is the onboard controller.
This did *_NOT_* happen with OMV 1.5 (kralizec)
Your still using omv 1? Wow I've used omv from way back then but I'd maybe recommend updating to omv5 now
No, it will only take care that the system is rebooted if something strange happens. This is a useful feature for headless servers. But it is not a service that is really required to run the NAS.
the issue appears to be with NFS switched all my devices to use SMB and the issues have now stopped. someone linked another thread with similar issues where it appears the kernel is the issue and downgrading resolves the issue but since I've switched all my devices i haven't tested.
I'm not at home during 2 weeks, so cannot perform any test for the time being. Did you on your side?
If you did, may you please share with me how to change to older kernel and I'll be pleased to do some testing.
no as i switched everything over to SMB and the time it took to rescan the DBs on the pis is making me hold off switching again.
Same for me, no more reboot: this is clearly caused by nfs.
On my side, I've kept NFS enabled but I'm not mounting any shares: it implies the issue is coming from the mounting process.
Now the question is 'how can we move forward to get this investigated by Debian??'
Have you attempted what that other thread states about changing the kernal to the older version and seeing if you can then use NFS?
Well been about a week now and no restarts so guess turning off NFS has cured it for me.
Im not sure if a drive in my raid is failing or if its another fault. i have received two emails one last Monday one last night saying
The following warning/error was logged by the smartd daemon:
Device: /dev/disk/by-id/ata-Hitachi_HDS5C3030ALA630_MJ1313YNG4UVSC [SAT], failed to read SMART Attribute Data
the syslog just shows the same error, the smart extended information shows https://pastebin.com/sKfS5Hvc
i'm assuming this is something to be concerned over? if it is a drive that needs replacing what do people recommend for drives these days bit out of the loop on drives.
I use SMB for my Android devices. And NFS between my OMV servers and between OMV servers and Ubuntu Clients.
The NFS shares are all created in OMV, but I mount all the NFS shares in the network, on all the Linux clients and servers, using autofs and on my Ubuntu MATE laptop I also cache NFS using fscache and 128GB NVMe storage.
My issue is less erratic and would randomly do it from a period of time so far it's been a few days with NFS turned off and the raspberry pis using SMB instead but so far no random reboots.
Yes, it works. You just have to set them up as different TV adapters. I had to continue to run until I completely switched to cable / IPTV via Fritzbox.
ive seen a few mentions of fritzbox but when i google it i just find routers is it somthing you can share info on?
this is what I did also today as I don't see other option to increminate NFS... I've kept NFS shares on OMV, but I've removed my NFS mounts on my Ubuntu client and I'm using Samba.
So far so good, today no reboot. I'll see in the coming days if this is confirmed.
Good to know I've changed the paths so far on the pis there currently rescanning to the new paths annoyingly. My issue isn't as excessive as yours mine can be a few days to a week before it does it the soonest was 1-2 days.