Posts by ParadingLunatic

Well...I'm now at a point where I really don't know. I've pointed docker to a new location on my main storage disk (that is NOT a shared folder) and let it create the folder itself. Tried pulling and creating a new instance of FreshRSS (all this is while SSH in as root) just to test it out using docker-compose....failed. Loads of permission denied when it was trying to chmod during the setup. Checked to see if dockerd is running as root and it is. Decided to change it back to /var/lib/docker and try that as well. Same problem. So now I have no clue what the issue is or why I'm having it.

That or it could be an ACL issue. I really have no clue. I'm almost tempted to nuke my entire docker configuration and start from scratch hoping to fix it.

Ok, so I THINK the issue might have to do with a umask issue but not sure how/where. I checked the shared folder where my docker data is stored (we'll called it /dockershare/docker/...) at /dockershare/docker/containers/xxxxxxxxxxxxxx......every single hosts and resolve.conf file were all 640 with owner of root:root instead of 644 and root:root.

I really would love to get this fixed as it'll allow me to finally move some of my dockers off of the VM and on to OMV....as well as get rid of future headaches when I roll out future containers.

I'm not sure if this is an OMV issue, a Docker issue, a docker config issue, an image issue, or a local filesystem rights issue. It seems like some of my Docker containers that run their processes as a user other than root, have problems with DNS. For example, my Nextcloud container has been unable to check for updates. The process runs as www-data. When I run "docker -it -u www-data nextcloud /bin/bash" and then run "curl http://www.google.com", it fails to resolve the url. If I connect to the container as "docker -it nextcloud /bin/bash" and run "curl http://www.google.com" it returns data as expected.

I checked the rights of /etc/resolve.conf and it was set to rw only for root and no other permissions (600). After setting the permissions to 644, suddenly everything worked.

So my question is...is this issue caused by the container, by docker, by the docker config, or by the underlying FS permissions?

I have docker using a shared folder instead of the default /var/lib/docker location. When I created the Nextcloud instance, I pointed it to the location I wanted and it created the folder for me so the rights on the "config" folder should be correct. Although the config folder is mounted to /var/www/html within the container anyways.

I have docker running on an Ubuntu VM (completely separate from OMV), and I've never once run into this issue on it. Granted it's also using the default /var/lib/docker. When I've run into this issue on my OMV system, I would even test it on my Ubuntu system and wouldn't have the problem there.

Quote from tannaroo

Hi all.

I tried to install Home Assistant on OMV5 through portainer which I successfully did. But after I create my Home Assistant account and log into Home Assistant, i do not see the addons or supervisor icons which many tutorials use to help setup Home Assistant - have I missed something?

This probably has something to do with the recent announcement (which has also been reversed) that Home Assistant will no longer support generic linux installs, or other unsupported installs. If you only installed the Home Assistant container, you're probably missing the Supervisor container which is what gives you all of the addons. If that's what you're looking for, you might have a harder time getting that running (and keeping it running) soon.

Yup, I actually I have a user called dockeruser which is given rights to the docker group. All of my containers are created and run using this account and all seem to work fine. The only difference I notice is that this particular container does a chown 1000:1000 and then switches to user "node" within the container during runtime. I believe it's the only container I'm running that does something of the sort. Most of them you pass a UID/GID as an environment variable, although I'll still do the docker run as the dockeruser account.

I have numerous docker containers running all without issues, except for one which I had to do a workaround to get working.

It appears all of my docker containers run the apps inside them under a root instance.

The one container I'm having a problem with runs it's application (a node instance) as a non-root user. The problem is it doesn't have any network access. I tried to troubleshoot this by attaching to the shell session within the container and tried an nslookup which failed. Tried to run a ping but ping required root access (which was odd but whatever). I then closed the session and reattached to the shell as root and had no issues with nslookup or ping.

I installed docker on an ubuntu VM, pulled the same image and copied the folder with all of the config files over to it, mapped the volumes, etc and ran the docker container and it had no problems at all running as the image was written.

Back on OMV, I deleted the image, and using portainer I copied the dockerfile information but left out the following lines:
RUN chown 1000:1000 -R /app
USER node

Ran the image, pointed the volumes the same as before, and it worked just fine.

Do the same, but re-add those lines, and no network connectivity.

Is there any specific reason why the docker install on OMV will deny network rights within a container when the program running in the container is run by a user other than root? I'm pretty sure I tried running the container as a different user and had the same issues.

Quote from ryecoaaron

It is really tough when I don't write the code and have no good way to test. I made some changes. Can you test them? If yes:
sudo wget -O /usr/sbin/omv-snapraid-diff https://raw.githubusercontent.com/OpenMediaVault-Plugin-Developers/openmediavault-snapraid/master/usr/sbin/omv-snapraid-diff
sudo chmod +x /usr/sbin/omv-snapraid-diff

Looks good! Diff finished without errors.

Quote from ryecoaaron

I really got burnt by this pull request not being tested. I will look at it.

It happens. I didn't see anything mentioned yet which is the only reason I said something. I'm sure what you guys do isn't exactly easy.

I'm having an issue with Snapraid ever since the 3.7.6 update.

I'm getting a syntax error during the cron job that runs nightly.

/usr/sbin/omv-snapraid-diff: line 490: syntax error near unexpected token `else'
/usr/sbin/omv-snapraid-diff: line 490: `else'

I use nextcloud to share pics, vids, files, etc with friends and family that live all over. I also use it to sync bookmarks from multiple browsers across multiple devices so they all stay in sync. I was recently playing with the RSS aggregator but it's not quite as full featured as I'd like so I'm sticking with tt-rss.

Quote from lulu

Actually I am running kodi 18.2 on a Raspberry Pi 3 B+ and I running a NAS with OMV 4.19.0-0.bpo.2-amd64. My media is also stored on a pool of EXT4 file systems using the Union Filesystem with SnapRaid. The Issue started, when I had to change a disk in the SnapRaid array.
I had the same Problems on Kodi 18.0.
Playback stops after aprox 1 hour, when I restart the playback it stops after a few seconds. After restarting the NAS the problem is gone (for a while).
No Problems when using MiniDLNA on the same NAS. Only have this issue, when using NFS.
Maybe I should delete everything and reinstall OMV

Not sure how much that'll help. I just recently upgraded from OMV3 to OMV4 doing a fresh install.

What options do you have set for you Union File system?

I have the following set "defaults,allow_other,direct_io,use_ino,func.getattr=newest,noforget"

use_ino, and noforget are supposed to help with NFS, especially with Kodi. There's nothing in the FAQ for mergerfs when it comes to kodi with NFS and using direct_io, but there is a comment in there about NFS and direct_io helping write speed, so I have it set since I do write files via NFS. Kodi pretty much only reads so that shouldn't be an issue for you.

Otherwise I don't really know what else you can try doing except SMB or if you really must use NFS, perhaps edit your /etc/fstab on your Raspberry Pi to mount your NFS in v4 fashion (don't use xxx.xxx.xxx.xxx/exports/folder....just use xxx.xxx.xxx.xxx/folder). This won't work though if you're going through with the Kodi gui and browsing NFS as the library used by Kodi doesn't support NFSv4.

Quote from lulu

I still have the issue with playback stoping after aprox. 60 minutes.
I am a beginner with OMV and Linux.
How can i remove the fsid=0 entries?
THX

I'm honestly not 100% sure why I'm not experiencing the problem anymore. Depending on what hardware you're using for Kodi, you might be able to try using NFSv4. You won't be able to do this with a Fire stick though. You could with a Raspberry Pi (once again, depending on what you're using still, I use OSMC which provides a stripped down version of Debian I believe),

To do this you would need to edit the /etc/fstab to add the NFS mount.

I may be able to help you, I may not. I have a pretty complex setup. For my primary systems I'm using Emby (sort of like plex but different) in a docker on OMV which pretty much manages my media (adds metadata, downloads subtitles, fanart, etc) and I use the Emby plugin for Kodi on some of my Kodi devices. On the plugin in Kodi I have it configured to use the plugin to play video, which basically streams it over http(s) over a specific port Emby uses. I do have one Kodi device though that doesn't use Emby and just plays direct via NFS. This is the one I WAS having problems with.

My media is stored on a pool of EXT4 file systems using the Union Filesystem plugin. This makes multiple disks look like one disk. It has its pro's and cons and is further complicating my issues. My media folder is then exported via NFS and SMB.

What version of OMV are you running?
Qhat type of file system do you have your media on that your exporting via NFS?
Also what are you using for Kodi?

Just thought I'd straighten a few things out.

The errors messages I was getting on the console of the one client ("NFS: Server xxx.xxx.xxx.xxx error: fileid changed") appeared to be when accessing via NFSv4 only. I switched the client to v3 for 24 hours and didn't get those errors. I've just changed back to NFSv4 recently after changing my exports so the NFSv4 exports don't have the fsid=0 entry. Was reading that could cause the issue I was seeing and read that NFSv4 does not need the fsid= value. I can edit this post or comment later if I notice that I no longer receive the errors. Either way, I doubt any of this had to do with my issues with Kodi.

I no longer appear to be having issues with NFSv3 using Kodi. I'm not entirely sure if it was a CPU issue (which it could have been since at the time my processor was just about maxed out due to MergerFS and Crashplan hammering it) or if it was switching to no_subtree_check to the exports, or adding noforget to my MergerFS config. I have since moved to an entirely different motherboard and significantly more RAM and CPU power...simply because it fell in my lap.

All I can say is, after going to OMV4, things seem to take a little more tinkering and tweaking to iron out issues but I think this is all compounded with my configuration (mainly, MergerFS/Snapraid as there seems to be quite a few issues stemming from that in OMV4).

EDIT:
Confirmed, I'm not longer receiving the "NFS: Server xxx.xxx.xxx.xxx error: fileid changed" on my one client that was using NFSv4 after removing the fsid=0 entries in the exports file, and switching back to use NFSv4.

See that's the strange thing. Looking at at the other threads, it looks as if others report that all shared folders that are from the mergerfs pool fail to appear due to the timing. My problem is, it's just the one. All of my shared folders are from my mergerfs pool. But it's just the one shared folder that doesn't appear. I guess it's still possible it's a timing issue. I'll do some more digging to see if that's it.

I'm not entirely sure why this is happening but it seems to only happen with the "Homes" shared folder, which I have enabled for user homes.

Rundown....

"Homes" shared folder created and pointing to the "/srv/XXXXXXX/homes" folder on the filesystem (it's a mergerFS filesystem so the ID is long).
Plenty of other shared folders created under this same /srv/XXXXXXX/ location as well
Under users > settings tab > enabled homes folder and point it to that Homes shared folder.
SMB/CIFS under Home Directories, I have it enabled

Every single time I reboot the server, I lose the Homes shared folder, which of course breaks access to users shared folders. I can try to browse /sharedfolders/Homes and it's completely empty. All of the other shared folders are fine.

To fix it, I go to Shared Folders, edit the Homes shared folder, everything is correct. I browse anyways to "point" it back to the location, even though it's the same location as when it was originally set. Save, then apply. And magically it's working again.

And.....now that I'm typing all of this. I decided to check my /etc/fstab and there isn't an entry for the Homes shared folder. There's one in for all BUT that one, even though I set it every single time I reboot. Is there a reason this isn't getting applied to fstab?

Edit: Nevermind about fstab. I just realized those are my NFS shares.

added noforget but didn't seem like it fixed the issue. After the reboot I kept getting the errors regarding fileid changed. switched the subtree_check to no_subtree_check and although I'm still receiving those errors (much less frequently at least), it SEEMS like playback from Kodi via NFSv3 has got better. Tried it last night and it played through a video just fine. Haven't really had much time to check.

It could also still be a CPU issue on the OMV server. Crashplan has been keeping the CPU around 50-75% for a while now. Been trying to get that straightened up as well but that would be for a separate thread. Seems like it doesn't like reading from /sharedfolders/ and would rather read directly from the original mount point.

Quote from gderf

Try adding noforget to your mergerfs options.

Thanks! I'll give that a try. Just added it to my options and will reboot sometime tomorrow. Currently copying my Snapraid parity file from an old failing disk to a new disk.

I THINK I see what my problem is but not sure. Getting quite a few errors on the client of "NFS: Server xxx.xxx.xxx.xxx error: fileid changed".....Then proceeds to say what was expected and what it got. Obviously the xxx.xxx.xxx.xxx is the IP of my OMV server.

I can definitely confirm though that at least when it comes to streaming a video over NFSv4, I don't have an issue. I have read in numerous Kodi forums that you're better mounting NFS via fstab over browsing/mounting via the Kodi browser using nfs:// (uses libnfs). Although there's other drawbacks to doing it this way which isn't for this forum.

Just an idea of my configuration. All of my storage (except the system of course) is all on mergerfs/UnionFS along with snapraid. I'm not sure if this could be stemming from MergerFS, or from NFS.

My MergerFS config is:
Existing Path, Most Free Space
20GB min free space
defaults,allow_other,direct_io,use_ino,func.getattr=newest

I forgot exactly why I have direct_io on but there was a reason. I have the last option for NextCloud because without it, I would have to force NextCloud to scan the NFS mounts via a Cron job. Just recently figured that one out.

The exports for the most part are all rw,subtree_check,insecure except for one which is no_subtree_check. Experienced the same issue on exports with both subtree settings.

Although...now that I think about it, this might be the NFSv4. Noticed that there's exports under # NFSv4 - pseudo filesystem root which are (ro,fsid=0,root_squash,no_subtree_check,hide).

Well, that didn't fix the issue. Last night, same thing happened with my one Kodi client. I'll need to see if I can find anything in logs. No clue where to start looking though. I checked the syslog on OMV yesterday and didn't see anything besides the connections and when I did the unmounts. Guessing the errors will be on the clients.