Well I didn't think of Jessie in particular for the update, but its nice to know that OMV 3.x will be the Version to look out regarding that. I was more interested in the bigger changes that are coming to OMV itself (like configuration backup, etc). I think this kind of information would help people like me who rarely read the forum to decide whether they should update or wait.
So as far as the discussion on Mantis goes OMV 2.x major change is the new extjs version?
Is there a rough timeframe when 2.x will be out of beta ? Or is the beta status only because of the plugin compatibility?
Is there a planned features list for 2.x because the roadmap in the wiki seems very old (http://wiki.openmediavault.org/index.php?title=Roadmap)
Thank you!
I was hoping for a solution integrated in OMV but I have no problem using the shell 
I actually want to get something very similar (only difference would be lvm snapshots I guess). But I am not sure whats the best way to configure the incremental backup because all backup plugins seem to depend on OMVs share-system and I would prefer an option that could be monitored via OMV.
Could you post a little bit more details about your current configuration (programs/scripts used, maybe configs, excludes,...)?
Hi,
I wanted to setup a backup for my system (root filesystem) and I thought about using rsnapshot for the task as there is already a plugin for that. But as I installed and opened the plugin it was only possible to select "Shares" as source and target. What is the reason behind this? In my opinion it makes no sense to backup one share to another share on the same system.
I thought I could get around the manual configuration of a rsnapshot job.
Is there an approved alternative for a complete (file, not image based) system backup? The backup Plugin offers some third party imaging tools like Clonezilla, but I want to be able to restore parts of the system or restore to a smaller partition so i would like to have a file based backup.
I am using a raid1 and lvm for my system drive.
Ok I misunderstood how pm-is-supported works. So actually Suspend is not supported on my system. I guess there is nothing I can do about it except for waiting. I've a brand new NAS based on the Intel Avoton platform so maybe there is still something missing in Debian.
I'm experiencing the same problem on my system.
The "Suspend" Option in the autoshutdown plugin does not work. But I dont think its an issue in the script because sudo pm-suspend does not work either. I have OMV 1.0.23 and backports Kernel 3.16.
When executing sudo pm-suspend nothing happens. I cant see anything in /var/log/pm-suspend either. pm-is-supported claims that my system supports pm-suspend.
I just installed the latest backports-kernel (3.16-0.bpo.2-amd64) and it works without problems, so i removed the omv kernel
I received an answer in the bugtracking system where Volker describes the following solution (which is at least for me the best solution possible):
Zitat von votdevAlles anzeigenYou can define some environment variable in /etc/default/openmediavault to customize the smb.conf to your requirements.
The variables are:
OMV_SAMBA_SHARE_CREATEMASK
OMV_SAMBA_SHARE_FORCECREATEMODE
OMV_SAMBA_SHARE_DIRECTORYMASK
OMV_SAMBA_SHARE_FORCEDIRECTORYMODE
e.g.
OMV_SAMBA_SHARE_CREATEMASK="775"
After modifying /etc/default/openmediavault you have to recreate the smb.conf file with
# omv-mkconf samba
After changing these variables every new share and all existing shares use the (for me) correct permissions. The 2nd issue I described in my first post is actually Windows related. OMV seems to do a reload of the samba configuration and therefore the connection to the clients is not interrupted. Active connections are not affected when permissions change, after a clientside reconnect everything works as expected.
I'm marking this thread as solved, thanks again for the exceptional support in the forum and bugtracker 
In the present default configuration of a smb share the permissions for every new file that is created in that share via smb are 755/644. You can only change the permissions of the share itself when you create it. At least thats how I understand and experienced it.
This is because every share in the smb.conf is created with the following masks:
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755In an office scenario say a co-worker made an edit I did not like to a file and my original was gone, I would be f'kin pissed. The other users can grab a copy of the file and edit it and save a new copy. I do not see how this is contrary towards productivity. This is my opinion and many people's opinions can vary.
Offices is a completely different environment and hard to compare. Normally in a bigger office this would be achieved via acls on Windows machines and probably shadowcopy. But I always set my environment up in a way that there are shares specific to users (like his documents) where only he has access or maybe some other user read access, and a share for collaboration where everything else is stored that both users need. Because otherwise it would not make much sense to even have the possibility to assign more than one user r/w privileges. But I understand this decision and would welcome a checkbox to disable it per share instead of editing my smb.conf.
Edits to your shares on the the smb.conf will not be reverted unless you edit/delte the share in the smb/cifs, which is unlikely. They are pretty static once you create them.
Thanks, then i will do it manually.
On documentation, it would be nice if we had documentation for everything. I love to read manuals and I can understand this. But you have to realize that OMV has developed so fast in the last 2 years we would be editing the documentation constantly. There have been videos made by some mods and they are worthless now because of changes. At some point in the next year maybe we can get someone to start on this project.
Maybe I was a little bit inaccurate with what I meant. I was actually thinking about a small text somewhere in the share-creation-dialog like "Attention: Only the owner can edit and delete the file even if r/w permissions are set for another user". But I'am not very good at these kind of texts .
I totally understand that a rapidly growing project is hard to manage and keep updated especially with only one major developer and I'am impressed how well thought out OMV seems to be for such a small team.
We try our best and all time by people involved is donated. Very few people have tried to accomplish big things. We are always here on the forums to try and answer your questions.
I'am really happy about that fact and I really appreciate the extremely good support here on the forums.
On 2nd part, it is way Volker did it for some minimal security in the smb.conf. You are free to edit that file for your individual shares to allow chmod you would like.
In my opinion this is breaking much more than it helps for security. Also this brings inconsistencies in the configuration because if I set the read/write privilege for two users I expect that both users can read and write to all files in the share, but thats not the case (and its not documented). For me network shares are for collaboration between users, but the current default somehow assumes a one client scenario. The simplest way to improve this would be a checkbox to disable this or enable if you want this protection.
Do you know if OMV will revert my changes if I change the samba configuration in the gui ?
PS- There are a million different scenarios you can setup with SAMBA. So when you create something like OMV you have to try a make best decisions that would suite the majority of users. Decisions have to be made in plugins all the time too.
I totally understand this decisions but such undocumented assumptions make it really hard to get everything working (even harder if you migrate from different systems like Synology or a Windows Server).
It is very important what you choose with the drop down and if you read the description it is pretty obvious what you should choose
As I understand it this is just the initial chmod for the folder at system level. So I could change this easily after the creation. And the default (admin:rwx; user:rw, others:r) seems ok for me.
What I said there does not apply. I explained in following sentences. It is very important what you choose with the drop down and if you read the description it is pretty obvious what you should choose. But then the Samba is another thing. By the smb.conf it is obvious Volker did not want non-owners of a file/folder deleting the owner's files/folders.
Ok thanks now I understand why it is handled this way. But to prevent the deletion of files of other users the "sticky bit" would be a better option because it prevents the deletion but not writing to the files.
Edit:
Sorry, the sticky bit would only prevent deletion of files which have the same owner as the directory.
I think that the current solution in protecting the userfiles is very counterproductive in a multiuser/client environment. For example I have two smb users because one user needs more shares and rights than the other, but some shares are used by programs that both users need to use. In the current setup absolutely no collaboration is possible. For me this would be unacceptable. There should be at least an option to disable this "feature".
When you created your shared folder you chose wrong drop down.
I assume you are talking about the permissions dropdown.
I did only choose the path via dropdown as I thought that the defaut values for the permissions were right? So what would be the right dropdown to choose?
Well... my Windows machine does not recognize permission changes until a reboot. Even if I restart Samba manually.
Is there a way to check if OMV is reloading the config or restarting the service? I don't see anything in the syslog, but i dont know if OMV does a reload or a restart (I guess a restart would be visible in the syslog).
On Windows the permissions are updated when I restart samba on the server. I don't know if a reload of the config would require a clientside reconnect to take effect.
der_Typ schrieb:
If there are two users with r/w privileges in OMV(set under shared-folders->privileges), I cannot write to a file that the other user has created. E.g.: user1 creates a file in share test, user2 opens the file in share test, adds something to it and tries to save it -> permission denied. I guess that should not happen. I tried to figure out the cause and I guess its because every file has 644 as permissions where it should be 664 (every file created via smb gets 644 as default). Its the smae with directories, If user1 creates a directory, user2 cant create files in it.
You can request a fix for that on the bugtracker, I'm not sure if you can set the for directory mask (and file mask) via the extra options.
Thanks, I just did http://bugtracker.openmediavault.org/view.php?id=1116.
It should restart the samba service when you apply the config changes already.
At least on my system it does not . I have to do it manually. Just to clarify I'am only changing the privileges in "Access-Rights-Mangement"->"Shared Folders" nothing else. After clicking apply the smb service is not restarted and the changed permissions are not active
If you have a folder that you want users to be able to write you should just use chmod 775. The data disks are not executable and this is the default chmod when a folder is created. So if you have a folder you want to fix recursively:
change directory to one level above the folder
chmod -R 775 foldername
I already know that 775 would fix my problems but every new directory or file would be created with false permissions so it would be only a temporary solution. And somehow all new files I create get 744 instead of 644 via smb. Here is the share, files and folder I created for testing, everthing is untouched and only created using OMV-gui for the share and a Windows client for the files and folder:
anon1@sirius:/media/52bf6400-6edf-4136-9a3d-5d0e815994ee/test$ ls -lah
total 16K
drwxrwsr-x 3 root users 4.0K Sep 23 01:17 .
drwxr-xr-x 8 root root 4.0K Sep 22 18:20 ..
drwxr-sr-x 2 anon2 users 4.0K Sep 22 21:05 Neuer Ordner
-rwxr--r-- 1 anon2 users 0 Sep 22 18:23 Neues Textdokument (2).txt
-rwxr--r-- 1 anon2 users 0 Sep 22 20:29 Neues Textdokument (3).txt
-rwxr--r-- 1 anon3 users 0 Sep 22 20:50 Neues Textdokument (4).txt
-rwxr--r-- 1 anon2 users 0 Sep 23 01:17 Neues Textdokument (5).txt
-rwxr--r-- 1 anon2 users 9 Sep 22 20:22 Neues Textdokument.txt
This is the share definition in /etc/samba/smb.conf:
[test]
path = /media/52bf6400-6edf-4136-9a3d-5d0e815994ee/test/
guest ok = no
read only = no
browseable = yes
inherit acls = yes
inherit permissions = no
ea support = no
store dos attributes = no
printable = no
create mask = 0755
force create mode = 0644
directory mask = 0755
force directory mode = 0755
hide dot files = yes
valid users = "anon3","anon2"
invalid users =
read list =
write list = "anon3","anon2"
Also the better way to "fix" something like this would be
find /path/to/base/dir -type d -print0 | xargs -0 chmod 755
find /path/to/base/dir -type f -print0 | xargs -0 chmod 644
because otherwise files would get exec permissions when using -R switch on chmod.
At the moment I'am trying to move my files from my old Synology NAS to my new OMV. I have already copied all my files via rsync and I'am now trying to fix the permissions because everthing is 777 atm.
To determine which permissions are needed by OMV i created a test folder and simply set the permissions accordingly (775 for folders and 644 for files (getting rid of execute for the owner); the share itself has 2775). So far so good.
But I ran into several problems after this and I guess some of them are bugs (I'am talking about smb only):
I hope you can help me setting these things up correctly.
Thats why I would suggest an option in the dropdown for the add-button so you can decide for yourself which users/groups you want to have in the gui to mess around. I think it would be a nice addition for more experienced users because you dont need to fire up a console to change the ownership of a share to get a specific service (e.g. transmission, pyload, web,...) to work. And if Iam not mistaken, you can only alter the permissins for shared folders within the gui so you cant screw up that much.
This would also lead to easier solutions to those "Iam not able to download something with plugin xy" threads.
I know that i can create groups in the gui, thats not the problem. I guess my description was a bit too specific.
I was talking about adding groups that already exist in Debian eg. debian-transmission in the OMV-Gui so that I am able to use the gui to setup the rights for the shares.