Posts by ZJohnAsZ

    Hi, while setting up MySQL using the plugin I encountered an access denial after changing my root password.
    At first I thought I made a mistake setting things up using the WebGUI, but after repeating the same precess 3 times, I realized that there might be something else
    I started searching for a solution on the forum and Google, but couldn't find any straight forward one. I could also see that many people seemed like dealing with a similar problem.
    I decided to post a resume of what to do to help whoever has issues like me with this plugin. If it's in the wrong section, I'm sorry, I'm still new around.

    What you should already have done:
    -Install (openmediavault-omvextrasorg 1.0.16).
    -Install MySQL plugin from the plugins (openmediavault-mysql 1.0.10).

    What leads to the problem:
    -Enable the MySQL service.
    -Go to the SQL web interface and login with root and a blank password.
    -Give a password to root@(localhost,, youromvname) and then... You can't login anymore.
    The web interface will give you an access denied, the service will be impossible to stop or restart and you will have error messages while trying to uninstall it.
    From what I could read the reason is that the user debian-sys-maint's password did not synch properly between /etc/mysql/debian.cnf and mysql.user.
    This user is the one with the rights to start and shutdown MySQL.

    What to do:
    1- To make sure we are at the same point to start with, completely remove MySQL from your system. The steps at the end of this post help with it: Also MySQL Problem with OMV 1.x
    2- Reinstall openmediavault-mysql 1.0.10 plugin
    3- Enable the MySQL service, log and set your root password.
    4-Open a SSH or use the CLI on your OMV machine.

    5-Reboot your server. Well you could try restarting the service, but for me it didn't work. I had to reboot and tadam! It works!
    Now, the service runs properly and you can access the management site.

    Instead of the 2 lines I gave above it is possible to run this one instead:

    GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY 'the_password';

    From what I read it's not recommended for security purposes.

    I hope it helps, this is my first attempt at a guide here. :)

    Main Sources:
    Also MySQL Problem with OMV 1.x…to-change-it-back-216586/…ebian-sys-maintlocalhost/

    I'll try to restart manually. But now I'm not sure what is right. I answer from ZJohnAsZ collided with your one? Or both ansewr are correct?

    Click on Aplly button, my user is added into write list in smb.conf

    I missed that part, but, subzero will correct me if I'm wrong, I think that even if you add the user to the write list using samba extras, if you denied it write permissions at the filesystem level, it won't work.

    If I good understand, the linux permissions are still controlled for users which successfully go through "Privileges" funnel. That means that "Privileges" don't override permissions, just help to speed filtering. Am I right?

    Well, yes

    From my point of view, checked "Read/Write" doesn't filter anything.

    It changes something depending on what permissions you gave when you created your shared folder.
    When you create a shared folder you have the permissions: Administrator=(root): read/write, Users=(all the users you will create with OMV): read/write, Other: read-only.
    In your case, you kept any user in your OMV to write in that particular shared folder because you gave read-only to users.
    Instead, give the group Users read/write permissions and create 2 new groups: admins and members for exemple. Add your metal palo user to the admins group and then you could not tick anything or tick read/write.
    To the members group you can allow read-only. If you add users to it, they won't be able to write. At the base, it is like giving all permissions to all users, but you restrict them with privileges.

    Sorry, it took me more than one day to give feedback on my problem. I have been busy on another matter with work.
    I figured out a solution with the help of a tutorial from subzero. :)

    My solution with the help of subzero:
    The way I dealt with the problem was to add a new user with no password

    1-Create a new user with no password. sudo -useradd pcguest -N
    2- Log into OMV and edit the user created.
    Comment: guest account
    Shell: /usr/sbin/nologin
    3-Give the privileges I want the new pcguest user to have over my shared folder.
    4-In OMV, Service SMB/CIFS, I tick Null passwords.
    5-When I access a shared folder from Windows, I can now type in pcguest without password and will have the privileges accorded to it.

    This is it! You don't need to allow guest access anymore, it's like a workaround (on which you have control) the whole anybody guest mapping of samba.

    It is because you gave read-only to users.
    When you create a new shared folder, leave the permissions as they are.
    You have to manage it with the privileges at the user level or group level.
    I am not an expert yet at how it works exactly, I'm new like you. From my experience, privileges > filesystem permissions. You have to see it like a funnel, one on top of the other. First it looks at the privileges and then at the filesystem permissions. For the privileges to work as intended when you tick and untick them, you have to leave the permissions to what they are when you create new shared folders. In your situation, like I said at above, you blocked write permissions to any user at the filesystem level, it means that even if you allow any user at the privileges level, he will still be denied to write. As for the ACL, see it like a way to give you more room at the filesystem level. It gives the possibility to add a groups and users to the basic filesystem permissions already allowed. Personally, the way I deal with it on my server is to create my shared folder with the default filesystem permissions, then create groups and filled them with users and set all their allowances with privileges by group. If someone feels like to correct me, I could be wrong, so do it if needed.

    Best of luck! :)

    The way I found to be able to have access to my different users' home folders via the FTP service was to add them as shared folders and then add them to the service. If you manage the shared folders privileges and deny access to the users they don't belong to, only the user's home folder will be listed with the other shares he has been given access to through privileges. I find the way to deal with the FTP service under OMV good as it is. It is secure and no need to deal with symlinks.

    Read-only on share
    Read/Write on public

    If you look at the settings I posted top, this is my actual configuration. I went back to it after trying different things.
    I think that the problem comes from the fact that nobody is not part of the groups which are given the privileges needed to access the different share.
    -Keeping the privileges settings and clicking ACL to give nobody the needed permissions, but nothing.
    -Setting privileges to nothing and managing all rights through ACL gives all user Read/Write on all shares.
    -Trying using CLI to add a user pcguest with a blank pass and map it to the guest account in samba didn't work.

    No matter what I try I keep getting a log box asking for a password when trying to access it as a guest. With the config I posted at the beginning of the thread, everything is perfect except that I can't use the guest option. I am pretty sure that for some reason the nobody account doesn't get through the privileges level because it is not part of any group created. Maybe, if the account nobody is added to the privileges window, it could solve the problem? I don't know, this my noob point of view, I might be missing something here. As I said before, this is not such a big deal, I can manage having a guest account with a password and just hand it to the ones that need it.

    After giving some thoughts to your suggestion I think I misunderstood it. If I go like you say, I would have to set no privileges at all and manage everything at the filesystem level. Won't I run into trouble with other services later if I change the default root:users on the different shares?

    Well, I give up. I did try that too. I created a new user with a blank password using the CLI. I also tried creating a user using the WebGUI and then removing its password with CLI. I used this in the extras: guest account = pcguest
    map to guest = bad user. Nothing worked. I don't think that setting shares with guests allowed and login users is that unusual. It should be something you could try to implement in the future.

    My solution: set a guest user with a password and give it to the users with no logins. I just hope that multiple users can use it at the same time...

    Should a bug report be submit about this?

    Thank you for all your help though, it is really appreciated.

    In the end it wasn't solved because it won't restrict any users if I use the ACL. It's logic, all the created users are part of the group users that has read/write access.
    Isn't there a way to add nobody to my members group? It would solve everything. Or can I add groups to the write list instead of users? It doesn't work when I do it. It would be easier to add users by groups than one at the time and would automate things when I add new users.

    I think I figured it out. I will confirm it tomorrow after a good sleep. I decided to untick everything in privileges and manage all the permissions with ACL.
    I messed around with different configs though, and I really sleepy, so there might be something else, but for tonight I come to the conclusion that this is one or the other. If you want guest access the way I do you need to use the ACL and not touch the Privileges options. All in all, it seems like working for now! I will add the solved tag tomorrow after confirming that this is the only thing I did.

    Good Night and thank you! :)

    I did try to give read/write to nobody using acl and nothing. You know what, instead of having a headache over this little inconvenient, I will setup a guest account with a password and give it to the occasional users. It should also make it simpler when I want to set my ftp using the same permissions/privileges, accounts and group.

    Oh, sry, didn't see your second post, I'll give it another try with this. :P

    I surfed with lines u gave me and adding some modified versions of them and nothing. I also came to the conclusion that it must be because nobody has no permissions, but I thought it would have them because I gave others write in public and read in share. I edited the /etc/group and added nobody to users and to members. Again, nothing... I guess, I will have to try and find another solution in the way to deal with it because I don't want to go the ACL way, I think it could end up messing my other settings.

    I mean, if I go ACL, that means I would have to set everything using it instead of privileges right? At what level does ACL works? On top of privileges or under it?

    I started a new thread with this, but this is the continuation of my last post in this one: Questions about OMV. Is it the right NAS distro for me?.

    Here is how I setup my different shares:


    USERS: user1, user2
    GROUPS: admins, members
    admins: user1
    members: user2

    Access Rights Management, Shared Folders:
    public (Permissions: root: read/write, users: read/write, others: read/write | Privileges: admins: read/write, members: read/write)
    share (Permissions: root: read/write, users: read/write, others: read-only | Privileges: admins: read/write, members: read-only)
    users (Permissions: root: read/write, users: read/write, others: none | Privileges: admins: read/write, members: read-only)

    Access Rights Management, Users, Settings:
    -User home directory
    Enable: Yes
    Location: users

    Services, SMB/CIFS:
    -General Settings
    Enable: Yes
    Workgroup: WORKGROUP
    Description: %h server
    Local Master Browser: Yes
    Time Server: Yes
    -Home directories
    Enable home directorie: Yes
    Browsable: No (If I tick it I can see 2 home directories, one called "homes" and another one with the with the account name. Both have the same path. Why does it do that? Is it normal? Why can't I only see the homes folder?)
    WINS Support: Yes
    -Advanced settings:
    Null Passwords: Yes
    Use sendfile: Yes
    Asynchronous I/O: Yes

    Services, SMB/CIFS, Shares:
    -public and share settings
    Public: Guest allowed
    Read only: No
    Browsable: Yes
    Inherit ACLs: Yes
    Inherit Permissions: Yes
    Recycle bin: Yes (0 | 2)
    Hide dot files: Yes
    I didn't select or add any other options.

    Everything works fine as long as I am logged on with existing USERS. They all have a home directory listed under their names. The GROUP admins can read/write in public and share. The GROUP members can only write in public and read in share. Although, when I try to access to public or share with a client that has no credentials, it prompts a log box. What should I do to be able to allow people with no logins to have read in public and share and write in public? I don't get where my mistake is here.

    I would go for the ssd too. I don't know if there are comparable tools to L2ARC and ZIL available under OMV, but your NAS would be ready for them when it will. In my opinion, ssd is the future for the main OS in a system, if u can, go for it.

    the system drive which is always spinning

    I'm still new to OMV, but isn't it normal behavior for the main HDD to always spin? I had my setup ready 2 days ago and I can always hear it spinning as well. My data drives are running smoothly and I can only hear them when the data is on demand or being written on.