SMB Errors on Privilege enablement

  • So I'm new-er to OMV, but I've been functioning for quite a bit now and getting things ironed out piece by piece as I go along. I've finally decided to start functionally using SMB/CIFS sharing on my local network for my systems to store data. I already had all my shares setup and ready, sorted out, and configured. My first goal was to get Docker up and running on a separate host, but mounting the storage on my OMV box through NFS/SMB. NFS didn't pan out, so SMB won and I was able to get that functioning. Interestingly, I never used the Privileges function in OMV but am fully functional (to my knowledge and understanding) with my Docker host using OMV for everything storage related. Mounts show properly, permissions look to be good, and everything is working as expected.

    Now for the problem - I recently tried to mount the storage on my local machine (OS X) and mounted successfully, but it seems I'm in read only mode. I can't actually write to the disk and it doesn't seem like I have the option to (or maybe my ignorance is showing here). I've mounted before without an issue, as long as the permissions were there and set correctly, I could write to the share. So doing some reading on here, I found the guide on setting up share permissions and that the Privileges need to be configured in addition to the file level permissions. So I read, comprehended, read some more, and decided to test it out. Hoping not to break my Docker setup. When I attempt to modify ANY of the privileges for any of my shares, I'm met with an error upon applying the change (shown below in code box, and attached as screenshot). When I do this, I also then see the services section show the red dots indicating an issue with the service for NFS/SMB which are enabled. And I can validate that if I don't reset them, there are in fact issues as the server can no longer mount the shares.

    So my question is, how can I resolve this as it sounds like enabling these Privileges is a core function of setting up sharing correctly in OMV, but I can't seem to apply them. I also tried unmounting everything and/or turning off the services first in case there was a dependency condition with currently active connections. No dice. It seems there is a bigger issue relevant to the exports being created on the system?

  • The error is kind of obvious. Nfs works by creating mount binds in the /export directory yo the /media disk folders. Just carefully go to /exports/downloads directory check there is no contents there, then check there are no mounts in that folder

    mount |grep downloads

    If everything is ok then remove the folder and try to configure nfs again.

  • Forgive my ignorance, I had seen the can't mkdir /export/downloads. The problem though I'm not understanding, I didn't create those in the first place - OMV did. So why is OMV creating these once, then throwing an error later on because they already exist? I didn't want to delete these or adjust this manually, as I figure that would cause me more problems than I'm already having (I fiddled with something manually when I first started, which forced me to scrap and start over because of manual intervention). So I've aimed at not manually intervening in the system functionality.

    The second piece of my confusion is - I wasn't aware SMB/CIFS created exports like NFS. NFS is not of concern here, I just happened to notice the NFS service was being screwed up when I did this in addition to the SMB/CIFS service. So honestly, I could care less about the NFS setup at this point. That's a later topic to address if I want to even bother using anymore, since I intended on my Docker setup using the NFS more than SMB/CIFS - but permission woes have forced me to use SMB/CIFS instead.

  • SMB/CIFS doesn't create bind exports. If you don't mind NFS then proceed to remove shares in the nfs server section and disable it so the error doesn't show any more.

    NFS server in docker is complicated since the container needs to run privileged to access the kernel. The nfs server binary (nfsd) comes shipped in the kernel is not a separate package

  • @subzero79 thanks for pointing me in the right direction. Sometimes I really just need someone to point one thing out, and or drive me further, to then find the root of my problems. I was able to successfully get the Privileges enabled on one of the other shares I tried with less importance (Temp). I deleted the NFS mount point, then changed the Privileges on the shared folder. This time it worked without the error message. Yay! 8o:thumbsup:

    Now I decided to continue with what I was initially troubleshooting, my inability to write to the share from my Mac device. Turns out when I was fixing all my permissions leftover from the Synology migration, I decided to place 0755 and 0644 permission sets on directories and files recursively. Well, that caused an issue writing from my Mac where I was authenticating as a user who was not the owner of the share. For simplicity and ease with Docker and permissions woes, I made a storage user (just called storage) that I use as the user inside containers, and making that user the owner made things easier. So no root ownership, but I did modify the defaults, as advised against in your Privileges and Permissions guide. Doh! X/

    Now here is a burning question for you - how the hell am I managing to have Docker, my local machine, and a remote camera writing to these shares without having ever enabled the Privileges before?

  • Ok I think I'm understanding this. Forgive me as I'm not a linux wiz, and certainly not when it comes to permissions. I think I get it enough to usually hold my own and follow the path of logic to get it right.

    So the part that confused me was this excerpt form the guide I was originally reading by you. Am I to guess then the magic that would happen if I left the default, is perms would be 755-root:users, and a end up setting extended attribs in the form of maybe ACL's to functionally allow the RW/R/NA set in Privileges? Just trying to finish following the process here so I know if I want to back track and fix going that route or continue on the path I'm on. So far its working well, and I usually like the idea that if it ain't broke don't fix it. But I'm trying to feel out potential future issues I could face before they happen and then I have to do all the work anyway. (At least right now it's fresh in my brain! :P )

    When users access a sharing service they have to pass two levels. First the the directives from the services apply for login and read write access, then the standard POSIX permissions apply as usual into folders and files.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!