Clarification on samba shares...?

Oh? So the ownCloud plugin is directly upgradeable to the main package? I thought the plugin was somehow "different" and thought it wouldn't be able to "talk" (and thereby upgrade) with the main package from the repos. I guess I assumed it was like comparing the Firefox application on a regular distro vs the Firefox "app" for Android. Both Firefox. Both technically on Linux. Different implementations.

The idea is to run the most recent ownCloud at home, mostly because we run it at work so having a more recent version at home is nice so I can get a feel for it early on, as well as take note to any bugs and report as necessary.

@ davidh2k, dang, really? The vast majority is done by him alone? Does he ever sleep?

Note: EDIT below.

Hey folks. Another question of mine just popped up so I wanted to ask here to get your insight. Figured I'd tack it on to this thread I started since it's pretty relevant.

I ran with the multiple share idea. Right now I have 10-11 shares or so. This seems "okay" but isn't exactly ideal. Some items I like to move between shares. For example, I have a Public share, which is a free for all everyone has write permission share. Files can be dumped there by other users using the "guest" samba account I created and then I'll move them to wherever it makes sense. For example, a friend of mine took a really long video of my daughter at her birthday. So he dropped it in the Public share before he left. The thing is, if I drag/drop that file from Public to Videos, it has to copy down to my laptop then right back to the Videos share. This type of behavior isn't really ideal.

In comparison, if I have /media/UUID/storage as the one and only samba share with directories underneath being controlled by POSIX permissions like I had before, it's the exact opposite. Since it's not traveling from one share to another, it's an instant transfer. This is the type of behavior I want. It's faster, cleaner, etc.

I started messing with groups in the web UI. This looked interesting and I thought I could make something work. Unfortunately it seems like I can only apply that group to the shares, and there's no GUI based way in the web interface to apply a group to a directory beneath a share. Is there a place to do this that I'm not seeing within the web interface?

The other thing is (building on that last idea) I noticed the reset permissions tab within shared folders. In the drop down there's various options for read/write/execute, but all of them are administrator:users. Is there a way to have my self-created groups populate there? I figured if I could create a group, then go to reset permissions, then have administrator:videos show up, suddenly I'd have that capability on the GUI level.

At this point I'm starting to lean towards just rocking one share and SSH-ing in to chmod everything in accordance to what I need. Right now I'm just trying to push everything with the web interface as much as possible first before I do anything more on the terminal level. I'm also trying to avoid ACLs if at all possible.

With that said, anybody have any ideas? Or is SSH-ing in for some chmod the best course of action?

EDIT - I didn't want to delete the above info in case anybody digging this up later could benefit from my original train of thought. I looked around for a bit online and it sounds like this is the nature of samba, as the client believes that the different shares are indeed different shares or "sections", which is why it ignores the straight local copy that takes seconds and instead pipes it through the client (laptop in my case) and back to the server on the other share. Users on other platforms were saying the exact same thing (OSX, etc). I understand that a bit better now.

I guess no matter how I slice it, I'm looking at some form of terminal work unless I want to wait for the files to transfer locally then back to the server to hit the other share. Disclosure: I love me some SSH/terminal. I was just trying to do this strictly by the web interface to see how far I could stretch it and what exactly I could do. On one hand, I can either SSH in and chmod +s and chmod 775 the upper directories (i.e. /media/UUID/storage/documents, /media/UUID/storage/pictures, etc) accordingly while using one actual samba share (/media/UUID/storage being the only share), thereby controlling everything in suit. So on that front, I have terminal work to do up front. Okay, fine.

On the other hand, there's a slight issue that might dictate a bit of favoritism for keeping the shares split up. Given the umask is 755 globally, if I (Jason) create a sub directory in the pictures share, say "1st birthday" for my daughter, that still gets hit by 755 permissions, thereby locking out my wife from being able to write additional pictures to "1st birthday", since after all, Jason is the one that created that directory in the first place. If I stick to this the OMV way, I can just reset the permissions in the web interface. I say the "OMV way" because the only options (as far as I can see) within the reset permissions field is for administrator:users. This wouldn't offer me administrator:pictures or any other custom group I created myself. So if Jason creates "1st birthday", that's jason:users @ 755. No write access for wife even though she is a write user in the privileges field. So I could reset permissions using the default (and only) administrator:users options to be RW for owner and group, bam, 775, wife has access with one click in the web UI.

So basically it boils down to this.

• If I keep my shares split, I can leverage the reset permissions option in the UI using the only owner:group option (administrator:users) to effectively 775 the directory quickly and easily, opening the door for multiple "write users" (samba) to write new files in directories I originally created.
• If I lump everything in one share, I still face the above issue (default 755 umask, etc), and this requires an SSH session to chmod the directory to 775.
• If I keep my shares split, I will either have to SSH in to mv the file or simply wait.

I view the benefit of split shares, and therefore, the reset permissions option as being more beneficial, since I can run in to that a lot more frequently than having to move a big file I'm too impatient to let cycle through its share1>>laptop>>share2 transfer.

That's it for my late night brain dump. If anybody has anything additional to add to the topic I'd be interested to hear it. Thanks!

Zitat von davidh2k

Just create an additional share that has '/' as path. E voilá, you got what you want.

Greetings
David

So to be clear, am I creating a single samba share at /media/UUID/storage, and then shared folders for:

/media/UUID/storage/documents
/media/UUID/storage/pictures
/media/UUID/storage/videos

etc?

By chance, could you post a screenshot of what you were referencing, or else confirm if my screenshot looks correct? Ignore everything else, aside from test, testdocuments, testpictures, and testvideos.

http://i.imgur.com/XJZzpuX.png

So you have test as a shared folder *and* samba share, then testdocuments + testpictures + testvideos as simply shared folders (not dedicated samba shares)

In this case when I created a new shared folder for testdocuments, I had to manually type in test/ in front of the path to give it /test/testdocuments. If I just give it a path of / I'm not able to locate it on the system...

I'm not thinking my screenshot is correct, as I explicitly gave my wife read only privileges to testdocuments, yet she can still write files to testdocuments...

This share vs share talk when we're discussing shared folders vs samba shares is making my head spin.

Is JASONTEST correct in this screenshot? I believe this is what you were referencing...

http://i.imgur.com/NdnIC7j.png

Zitat von subzero79

In samba that's called Enable permission inheritance enable the checkbox and that should override the default umask (755 to 775). This is the note on the configuration share in OMV for samba

"The permissions on new files and directories are normally governed by create mask and directory mask but the inherit permissions parameter overrides this. This can be particularly useful on systems with many users to allow a single share to be used flexibly by each user."

I was unaware of that info. That sounds perfect for multi user environments. I may not be an enterprise but as mentioned I do see value in things being structured in a flexible way. That said, I'm actually glad the default setting errs towards 755 instead. Thanks much! I'll give this a shot.

EDIT - I gave the above a shot. Works great. This will make things exponentially easier so both my wife and I have "full" access (775, root:users, both in users group) to be able to save pictures accordingly to the pictures share. I dig this.

I fired up a fresh install on a test server to tinker further. Unfortunately I'm getting no where. I have a single data disk as /dev/sdb. I created a shared folder for "storage", which is at /media/UUID/storage. If I create more shared folders by explicitly putting the path as /, nothing happens. In fact, in one case, my "storage" folder disappeared and it was renamed to the new folder I was trying to create on /. That may have been a goof on my part, but it made me feel good about doing further tinkering on a test server.

In theory it makes sense to me to create sub directories underneath the samba share, i.e. /media/UUID/storage as the samba share, and within there, the folders. Unfortunately I cannot do this in the web UI. I logged in via samba, created the directories, went back to the web UI, and added the shares by searching for the folder and hitting the drop down under "storage" to show additional folder options. I found my test folders, selected them, and it paired them what seemed to be correctly. Unfortunately, the privileges field has literally zero impact on /storage/documents, only /storage, which defies the entire point.

(I wasn't necessarily expecting the paragraph above to work, I was just experimenting to see what combinations would fly and wanted to document them here. Something tells me I'll be sticking with split samba shares so I can isolate read-write and read-only permissions for certain users in certain directories)

With some further clarification on the IRC channel from the one and only Davidh2k I was able to make more sense of what he was suggesting. I wanted to relay that here for future forum/Google searches from users who might be able to benefit.

A reminder that the idea is to have the ability to move large files easily. With samba, by nature, you cannot transfer data from one share to another without it passing down to your client system (laptop, desktop, etc) first. Despite it being the same system, even the same hard drives, the fact is the shares are split and operate independently. This is true for any OS/file manager/etc. It's a samba thing.

This is a rare need of mine, but having the ability is a nice addition. I can always do it via SSH, and sometimes I likely will, but hey, it's good to know GUI tricks too. All tricks are useful, whether GUI or CLI based.

The idea is to leave your shares independent. So I still have /media/UUID/pictures as a share, /media/UUID/public as a share, etc. Everything is in its own share so I can independently control what level of access each user has via the privileges feature. By creating *one* additional shared folder with the path as / (and afterwards also adding it as a samba share), this enables /media/UUID to be a share. With the share being /media/UUID, it makes pictures, public, documents, etc (despite already being their own independent shares) to act simply as folders underneath. Therefore, I can drag/drop files from one folder to another (from say public to pictures) and it's an instant transfer, much like mv over SSH/CLI. Folder to folder is instant. Share to share is not and requires a pull down to client/push back up from client to the other share. 99% of the time, this won't matter, but that 1% when I have a massive file dumped in Public, I can drag/drop it to Pictures, Videos, or wherever it may need to go instantly.

Some relevant screenshots in case they help.

Creating the actual share. I named mine Administration so it was obvious to me. This share is only accessible by me since, after all, I'll be the only one using it. You also need to share it out via samba afterwards as well.
http://i.imgur.com/5KZbldx.png

How all of my shared folders look now.
http://i.imgur.com/KtNTByQ.png

I decided to hide the Administration share by unchecking the browsable option. I can still hit smb://192.168.x.x/Administration manually, but it doesn't show up by default when I'm browsing. This just keeps things a little cleaner. Personal preference given what I intend to use it for.
http://i.imgur.com/pIJrxS1.png

That's it. Hope this may help someone in the future. Thanks again Davidh2k!

Zitat von davidh2k

This share to share behaviour will change with samba 4 and enabling the latest smb protocol version which will allow that share-to-share will do local file transfers instead.

Everything else: You're welcome.

Greetings
David

Oh really? That's interesting. Isn't Samba4 out though? Or is it just not in Debian Stable yet?

Zitat von subzero79

Is in debian backports, try it at your own. Syntax doesn't change that much in Samba.
Downgrade process is a pain.

Sounds like a job for the OMV backup plugin! (clonezilla live)

I'll pull an image and tinker with it later. Just to confirm two things, 1) is there anything else I need to be aware of? Or is it just install backports and presto, done? 2) I assume the OMV samba functions/features in the web UI is fully commpatible with it?

Zitat von davidh2k

Syntax hasn't changed, but you can't use the Directory Server of Samba4. (At least not via GUI.)

Greetings
David

...and the directory server portion is required for the local copying between shares? I thought that was more of an active directory style component...