Samba Share Types in OMV

Zitat von Krisbee

A whole extra plugin and webgui clutter when you could use "setfacl -b" or "seftacl -b -R" at the CLI?

The plugin does more than that. It can be used to reset the permissions to the default ownership and permissions. Including setgid.

Zitat von Krisbee

A whole extra plugin and webgui clutter when you could use "setfacl -b" or "seftacl -b -R" at the CLI?

Always nice when people think I waste my time on plugins. Take a look at what it is really doing - https://github.com/OpenMediaVa…r/usr/sbin/omv-resetperms

And the plugin adds a tab that shows where sharedfolders are being used. If those two tabs are "clutter", then it is great that is a plugin that you don't have to install.

Zitat von Krisbee

You've misunderstood. I know what the reset plugin does. No one is saying you wasted your time. My point is that AFAIK you cannot clear an ACL entry from the shared folder using the ACL webui page. For example, you can give a given group read/write access, but later cannot selectively remove this ACL entry via the webui.

That may be the case. I don't use ACLs and tell people not to. People are constantly having problems with them. Just another reason to not use them.

Zitat von Krisbee

"Extended Permissions are not native to Linux", which to my mind is incorrect. If you agree that "native" in this context means "designed to support", then clearly ACLs are native to Linux in both the kernel config and the various filesystems it's designed to work with (see mount options used in your /etc/fstab file). But an important question is which type of ACL does Linux support?

Technically you may be correct. However, Standard Permissions (Owner, Group, and Others) have been with Linux going back into the Dark Ages of computing. Extended permissions (or ACL's) where adapted to the Linux kernel well after Standard Linux permissions were originally implemented. Adding support to the Linux kernel or installing a kernel module, in my mind, does not make a feature "native" to Linux. Why? Just because the kernel supports a feature, or it's adapted with an add-on driver or module, does not mean the feature is "native" to the vast swath of packages in the Linux Userland.

Linux -> NTFS support is a great example. While the kernel has been adapted to NTFS, that doesn't mean the vast majority of Debian Userland packages will recognize NTFS file and folder permissions. Since new users like the idea of formatting an external drive to NTFS at a Windows Wks and shuttling it between an OMV server and Windows; telling them NTFS permissions are "native" to Linux is not productive. (This forum is littered with OMV/NTFS issues.)

It the broadest sense of the term "native", NTFS is not native to Linux. OMV will recognize an NTFS drive but the full extent of NTFS permissions are not configurable in the GUI. Hence, OMV is not fully compatible with NTFS.

________________________________________________

Any kernel feature that requires a userland add-on ( apt-get install acl ) is, arguably, not native. ACL's are an add-on that's very similar to NTFS' NTFS-3G driver and the Ntfsprogs add-on. The only real difference is that ACl's have been around longer. In the bottom line, there are many linux servers out there that don't have ACL's installed. Extended permissions (ACL's) are completely optional where Standard permissions are "integrated".

While experts can (and will) do what they want, OMV's GUI tends to attract beginners. With beginners in mind and in consideration of the server packages available that do not work seamlessly with ACL's, mixing Standard and Extended permissions is a bad idea.

Zitat von Krisbee

raulfg3 A whole extra plugin and webgui clutter when you could use "setfacl -b" or "seftacl -b -R" at the CLI?

Again, experts can do what they want. They might consider an Arch Linux server using the CLI only. They don't need a GUI.

Beginners, on the other hand, are another matter. Encouraging them to experiment with ACL's, on the CLI, without knowing what they're doing, is a recipe for a complete system rebuild. Conversely, staying within the capabilities of the GUI keeps potential damage to a minimum while keeping paths to recovery open.

Zitat von Borbio

It would be cool if that were part of the standard OMV UI.

Not everything can be part of core OMV. That is whole idea behind plugins. Plugins ideally distribute the development load as well.

ACLs are a bandaid to get Windows style permissions to work on Linux. They do not match native unix permissions and therefore will never be native in my opinion. But this is just a pissing match and not going anywhere. If the ACL editor needs additional features, then file an issue or a

merge request.

And while I have used resetperms, it has never been to clear up ACL garbage. I have never been forced to use it. I don't "need" it although it is helpful.

Zitat von Krisbee

Additionally, for someone using OMV6 who creates a shared folder and then wanted to just change the standard perms, they’d probably use the ACL page to do it,

Why? Someone will use "Access Control Lists" before "Privileges"? That is a serious question. I really want to know what the average user would use and why.

Zitat von Krisbee

Linux has evolved over time and an argument about what is or is not “native” to Linux based on longevity is surely bogus. Just as bogus is an argument based around implementations with both kernel and userland elements are somehow not “native”. No one would claim the NFTS filesystem is “native” to Linux, but where does your argument leave btrfs, yet another linux filesystem that supports ACL that has a relatively short history in Linux?

ACL values are stored in a file or folder's "extra attributes". That should tell you something right there (add-on). And yes, when it comes to file systems, BTRFS is a new add-on just as ZFS on Linux is an older add-on. Arguably, either of these file systems should NOT be used by a beginner without an understanding of what they are. On the other side of the filesystem coin EXT2, 3, and 4 are native. That's simply my opinion.

But, in the bottom line, ryecoaaron is right. If you think there are better ways to deal with ACL's, write some code and (maybe) get your approach integrated into OMV's ACL page.

Similarly, if you don't like the language I use when trying to guide new users in the permissions doc ("native" versus "add-on", etc.) feel free to write a doc of your own. (Making that statement seems strangely familiar.) I'm of the opinion that's not going to happen because it's easy to write a few critical posts, that takes 5 minutes or so, within a support thread. It's another thing altogether to create and support something that's usable by a broad cross section of users. (With emphasis on supporting new or inexperienced users.)

Zitat von Krisbee

I'm perfectly in tune with the idea that users should be steered away from the use of ACL . I don't use them nor need them myself. But rather than simply say "don't use them, they are a nightmare", would it be useful to have somewhere a clear statement as to the pitfalls?

Obviously, you haven't actually read the -> permissions doc that was linked in this thread. It's getting to the point where writing these doc's seems to be pointless; especially when experienced users jump into a thread like this one just to express their opinion (highjacked while helping users with actual problems). Again, this kind of chase down a rabbit hole is strangely familiar. One thing is certain - it's not productive.

Zitat von Borbio

Not finding that. Do you mean Storage > Shared Folders > ACL ? I thought(?) you suggested that I shouldn't use ACL settings.

You're in the right place. Unfortunately, the GUI presentation has Standard and Extended permissions (ACL's) in the same place under the ACL's tab. (The permissions doc explains this but OMV6's GUI's presentation is different enough to where confusion is possible.)

In the same window, at the top, you'll see user names with boxes to the right labeled Read/Write, Read-Only, and No access. These are ACL's. There shouldn't be any boxes highlighted there. If any of the boxes next to usernames are highlighted, clear them and resave with the recursive option checked.

Toward the bottom, you'll see Owner, Group, and Others. These are Standard Linux permissions.
For the purposes of the first test, from what I saw in your screen shot, you had them right and the recursive box appeared to be checked when saved.

__________________________________________________________________________________

Zitat von Borbio

Not sure what you mean here either. (1) There's a group called users, and the user with which I'm connecting to OMV belongs to it, but I thought(?) (2) users was created by Debian when I set up the server. (3) If browse Users > Users, I see a list of users, including mine, that belong to the group users. (4) However, under Users > Groups, I don't see users on the list. Again, I thought Debian set it up?

(1) That's what you want. It's default behavior. The group "users" exists as part of OMV's build and every user created in the GUI is added to the group "users" by default.
(2) I don't know if the group users is created by Debian or the OMV build. However it's a default group on the finished product.
(3) Under Users, Users, you should see all users you created. (System users shouldn't be in the list - at least they're not in my build.)
(4) I believe the group users is not listed in the groups window because it's a given - a default. On the CLI, using less /etc/group users will be there with all members.

__________________________________________________________________________________________

Zitat von Borbio

when I tried to add write list=@users as an extra option to SMB, I get some incomprehensible error when I apply the changes:

I don't know why you got the error. However, write list = @users is added as shown below in edit mode.



The write list option shouldn't be required if the SMB share is not set to Read Only. But since you're experiencing something odd, it's worth a try.

I haven't seen the error you referenced before. If it persists, when you attempt to save a change, you might consider deleting the SMB share and recreating it.

________________________________________________________________________________________________________

Zitat von Crashtest

- You could try setting the Shared Folder to "Others" Read/Write/Execute AND the Group users to Read/Write/Execute. Set the SMB share to "Guests Allowed". Then see what happens. (This is wide open permissions for all clients on the local LAN.)

Zitat von Borbio

Sorry, I don't follow what you are suggesting here. I guess I need screenshots or more precise instructions that work for OMV 6.x.

As follows :

Shared Folder (Set all to Read/Write/Execute and save with the recursive option.)

SMB Share

For this share, permissions are now wide open to any user on the LAN.

_______________________________________________________________

Zitat von Borbio

Sorry, again, I don't follow what you're suggesting. From the CLI, I was using chmod on a directory, not a user or group.

You said:
"I tried chmod u+x MyFolder on the OMV server, and after that I can copy the file."

That command allows "user" to "execute" a file. I don't know "why" this would affect a simple copy, but there are other possible command options that might work better.

The options for chmod "?"+x are:

u = user

g = group.

o = others.

a = all

The last might be best option which sets all to execute; chmod a+x MyFolder
This would be the equivalent of giving Owner, Group and Others "execute", in the GUI. Again, I don't know why "execute" would work, even temporarily, for a file copy. Read/Write should do it.

In any case, I wouldn't worry about this.

_____________________________________________________________

Zitat von Borbio

(1) No firewall. I'm on a LAN. (2) The firewall is on the router, and I'm not going through that. (3) The connection between client and OMV is on the same subnet.

(1) Mac's have a -> firewall. You need to look at how you're configured. If it's possible, set the firewall to "OFF" as a test. Otherwise, again as a test, note your current setting(s) and make the firewall very permissive.
(2) That is not necessarily true. If you're using DHCP, your router is also acting as a local DNS which makes it possible for the router to filter LAN traffic.
Another possibility is if there's a wireless connection between the client and server. For security purposes, some consumer routers may handle wifi traffic differently, when compared to wired connections.
(3) Even on the same sub-net, the only way to be sure the router is not involved is to statically address the client and server. (Rarely do app's use layer 2 - datalink - connetions.)

With the above noted, I don't think your router is responsible for your issue. On the other hand, it can't be ruled out. There are numerous consumer router OEM's; with some that go to great (crazy?) lengths to improve security.
________________________________

Let us know how it goes.

I just posted. See the above.

What is the output of: cat /var/lib/openmediavault/dirtymodules.json