SOLVED Cannot change permissions on SMB share linux client

[stevecyb]

I tried reading Methods for Fine Tuning Samba Permissions...but quite frankly, I don't understand any of it and certainly can't figure out whether/how any of it pertains to my situation. It seems to assume way too much prior knowledge.

I have a samba share, it works beautifully on windows, but when I try to access it on linux, it shows all files as 700 (rwx------) permission, owned by me, and my group.

That's great for many operations but I have an app that fails unless the permission is 766. Unfortunately, even though I am supposedly the owner of the file, I get a permission denied when I try to change the permission. Sudo also fails.

I was able to get an NFS share to work, beautifully (and the file on there needs those same permissions but at least I can make the change)!

Unfortunately one of my other clients is a windows box, and it flatly does not support NFS shares (not avaiable with that version of windows, and an upgrade is out of the question). So I really would like to get the Samba share to work properly on the Linux box! Otherwise I will be moving files back and forth between datasets.

OK the gory details: Client is Ubuntu 18.04. Freenas Server is a Mini XL running 11.2-U6.

 

[KrisBee]

How have you configured the perms and SMB share for your dataset in FreeNAS? If you have used the defaults of a "Windows share type" on the dataset with perms for a specific owner and group combined with a share definition that has "default permissions" checked, then I would not have expectd to see 700 as the perms when accessed in Linux? So, perhaps you have made changes to the ACLs via a Windows client and made them too restrictive. With the default SMB share settings in FreeNAS, I would have expected to see 0755 for both directory and file mode when the share is mounted in linux.

If your app is running on a std Ubuntu desktop as a non-root user (check in htop), then I would have expected the std umask of 0022 to apply and the perms would be 0755, not 0766, for directory access, and 0644 for file access. Those linux perms should match the default FreeNAS SMB share settings.

How are you mounting your SMB share in Ubuntu? Are you using an entry in /etc/fstab, mounting via the CLI when needed, or just via a file manager on your Ubunut desktop?

 

[stevecyb]

How have you configured the perms and SMB share for your dataset in FreeNAS? If you have used the defaults of a "Windows share type" on the dataset with perms for a specific owner and group combined with a share definition that has "default permissions" checked, then I would not have expectd to see 700 as the perms when accessed in Linux? So, perhaps you have made changes to the ACLs via a Windows client and made them too restrictive. With the default SMB share settings in FreeNAS, I would have expected to see 0755 for both directory and file mode when the share is mounted in linux.

I did use the defaults. I may have tried to monkey with things a while ago, but really, it would have had to have been from a windows client, trying to get into the share. The FreeNAS GUI doesn't give one a lot of control. But even when I was doing that, I was messing with one file, only.

Today, all files in the share show as 700 permission. And even though I own those file ( I am user "steve" on the client, and the owner and group are both "steve"), I cannot change their permissions.

I CAN do so with an NFS share. (So like I said, I could copy any file I want to work on from one data set to another...but that's cumbersome, and ZFS apparently actually copies the file, not just moving its directory entry.)

If your app is running on a std Ubuntu desktop as a non-root user (check in htop), then I would have expected the std umask of 0022 to apply and the perms would be 0755, not 0766, for directory access, and 0644 for file access. Those linux perms should match the default FreeNAS SMB share settings.

I know that 700 doesn't work, again because I'm supposedly the owner of the files.

By experimenting with files on the NFS share, I determined that the group and world permissions must be 6. It makes sense that a 2 would be in there, because the app will write to the files. I just don't see why the WORLD needs permission for this app to be able to read it.

(Note: I just did an ls with -n and the user id and group id of the files in the share are both 1000. I then did the same in my home directory and see the same thing. So the id, that underlies the name, matches too. Apparently the process of linking up to the share causes it to at least look like I own the files, somehow. I know on Freenas, the owner is "check" in the NFS share, not "steve")

How are you mounting your SMB share in Ubuntu? Are you using an entry in /etc/fstab, mounting via the CLI when needed, or just via a file manager on your Ubunut desktop?

The SMB share shows up in the file manager, I just open it up and there are the files (so I imagine some sort of mounting is going on behind the scenes). (I may have done something to get that to happen, but I don't remember what it was.) I can create files, etc; it seems as though I can do anything (other than a chmod or chown) because of the 700 permissions and the files belonging to "me," but this app insists on group and world permissions for some reason, and I can't do a chmod.

[edit: I just did something else. In the file manager, I clicked on one of the files, and looked at the permissions tab. It claims the owner is root(root) but that everyone has read and write--in other words, it's telling me I should see "root root rw-rw-rw-" on an ls -alF, not "steve steve rwx------" which is what ls -alF actually does show me. Now if that's somehow reality--I should be able to open the file with my app (world read/write) but I can't.]

 

[KrisBee]

Sharing the same data via both SMB and NFS at different times is probably what led to your situation. My advice would be to stick to SMB when accessing the same via both Windows and Linux clients. You can return your data to the default Windows perms using the FreeNAS webUI. Edit the dataset permissions making sure the the share type is set to "Windows" and check the "Apply permissions recursively" box. You can inspect the dir/file perms in the FreeNAS shell to see if this has worked as expected: e.g:

Code:

root@freenashpg8:/mnt/NasPool/wshare # ls -lR
total 1
-rwxrwx---+ 1 root   wheel  0 Dec 29 09:07 .windows
drwxrwx---+ 2 chris  chris  3 Dec 29 09:11 test

./test:
total 1
-rwxrwx---+ 1 chris  chris  0 Dec 29 09:11 test
root@freenashpg8:/mnt/NasPool/wshare # getfacl test
# file: test
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:--------------:fd----I:allow

In my example "wshare" is the dataset owned by user "chris". The "test" dir and file were created from Ubuntu 18. ( Note: At https://www.ixsystems.com/blog/library/freenas-11-2-u6/ there's a comment re: default windows perms)

Unless you want to dig deeper, I wouldn't be too concerned about how these perms are represented in Ubuntu as long as your app can access & create data as you wish.

P.S. I forget to say that chmod doesn't work in the situaiton you describe because a "windows sahre type" dataset as its "alcmode" property correctly set to "restricted". I'll leave you to google that one.

 

[stevecyb]

Sharing the same data via both SMB and NFS at different times is probably what led to your situation. My advice would be to stick to SMB when accessing the same via both Windows and Linux clients.

No, I don't think that can explain it.

Files that were never on anything but the SMB share have this issue.

I can move a file from the SMB share dataset to the NFS share data set, and it becomes accessible, or rather, I'm at least able to chmod it on the client to make it accessible to this funky app that needs 766 permissions.

When I move the file back, and look into the Samba data share from the client, it again shows as 700 and I cannot chmod it.

If I could just fricking chmod a file, that shows as me owning it, in a Samba share from the client side, the problem would be solved.

You can return your data to the default Windows perms using the FreeNAS webUI. Edit the dataset permissions making sure the the share type is set to "Windows" and check the "Apply permissions recursively" box. You can inspect the dir/file perms in the FreeNAS shell to see if this has worked as expected: e.g:

Done. Incidentally, there are no nested folders in the share. If the gui is to be believed, that's what gets affected by "apply permissions recursively"

Code:

root@freenashpg8:/mnt/NasPool/wshare # ls -lR
total 1
-rwxrwx---+ 1 root   wheel  0 Dec 29 09:07 .windows
drwxrwx---+ 2 chris  chris  3 Dec 29 09:11 test

I see pretty much this (though I do not see a file named .windows--I wonder why?). All files are 700 permission. However, the ownership is quite different.

In my case the files are owned by steve, group Users. Or sometime check, group Users (that's a file I moved over from the linux share dataset). In other cases, the files are shown as root, group Users.

In all three cases I cannot chmod the files, even though, on the client side, I am shown as being their owner. Since I cannot chmod these files, they are essentially useless to me unless I move them somewhere else (either to some local place on the client), or to an NFS share dataset) THEN work on them, and move them back.

Code:

./test:
total 1
-rwxrwx---+ 1 chris  chris  0 Dec 29 09:11 test
root@freenashpg8:/mnt/NasPool/wshare # getfacl test
# file: test
# owner: chris
# group: chris
            owner@:rwxpDdaARWcCos:fd----I:allow
            group@:rwxpDdaARWcCos:fd----I:allow
         everyone@:--------------:fd----I:allow

In my example "wshare" is the dataset owned by user "chris". The "test" dir and file were created from Ubuntu 18. ( Note: At https://www.ixsystems.com/blog/library/freenas-11-2-u6/ there's a comment re: default windows perms)

Well, now we might be getting somewhere. Or maybe not.

Since I have no nested folders inside the share, I can't do facl on one to compare, but the data files directly at the top level in the share show a facl identical to what you have...except the fd after the colon is missing.

Thinking :fd might be folder specific I created a folder and checked it, and sure enough it's there.

Unless you want to dig deeper, I wouldn't be too concerned about how these perms are represented in Ubuntu as long as your app can access & create data as you wish.

P.S. I forget to say that chmod doesn't work in the situaiton you describe because a "windows sahre type" dataset as its "alcmode" property correctly set to "restricted". I'll leave you to google that one.

Interesting. The aclmode appears to be set to "passthrough," not "restricted."

Other datasets that I set up as SMB (but don't actually share out) are set to "restricted."

NFS shares are set to "passthrough" too (and I can do what I want with them), but apparently having an SMB share set to passthrough has no effect. There's something else interfering, and I can make neither heads nor tails of anything I've found on google; it all assumes you know the rest of the system. I can't see how things tie together.

OK. I'm concluding that the whole schema for permissions on shares is grotesquely overcomplicated, and I have yet to find one place that explains the entire interaction between all of the things that happens, in a coherent way. Aclmode, aclinherit, the acls themselves, what happens with different share types, and what the result is on the share client, is still a total mystery to me. Whatever place this is, should probably explain the acls themselves, especially the complex windows ones. (And I wanted to do something a bit more involved in another place! Guess that's never happening.)

 

[KrisBee]

I don’t think anyone would argue that Perms & ACLs is a trivial subject, especially when dealing with a combination of FreeNAS, Windows and linux. Each has their own model for perms/ACLs. The FreeNAS system attempts to make this as user friendly as possible, but the advice on manipulating windows shares has been to do that from a windows client as shown in this often quoted video: https://youtu.be/QhwOyLtArw0

As using the WebUI appears not to have put the data you wish to share in a consistent state in terms of owner/group and/or perms, you’d have to do that on the FreeNAS server via shell commands. But first ensure the aclmode mode on the SMB shared dataset is set to “restricted” using a zfs command to set that property.

A possible (untested) alternative to sorting this out via the client side is to (a) share the data via NFS and chmod/chown those 700 files as required( see edit below), then (b) create a new “windows share type” dataset on FreeNAS to be shared by SMB with default settings apart from setting the required owner/group. With both shares mounted on your linux client, move the files from the NFS share to the Windows share. Then check file perms on new dataset on FreeNAS, and check if your app can access the data on the SMB mount.

FYI: I tested changing the "share type" of a dataset from uinx to windows via the WebUi in FreeNAs 11.2-U7 and the aclmode is not correclty changed from passthrough to restricted, so that looks like a bug.

EDIT: I'm assuming you want a consistent owner/group ofr this data, and you will use std linux perms given by umask 0022, i.e 0755 dir 0644 files.

 

[stevecyb]

As using the WebUI appears not to have put the data you wish to share in a consistent state in terms of owner/group and/or perms, you’d have to do that on the FreeNAS server via shell commands. But first ensure the aclmode mode on the SMB shared dataset is set to “restricted” using a zfs command to set that property.

And where can I find these shell commands clearly documented? Everything I have found has been absolutely impenetrable. I basically need an "Idiot's Guide To...", I'm afraid. [note: I was able to find the zfs command to set to restricted and did so, after several false starts (oracle docs seem out of date)]

I basically don't know how to do ANYTHING other than through the GUI, and I'm sometimes not even sure I understand the GUI. In fact, given that I have no idea what you're asking me to do below, I'm sure I don't understand the GUI either.

The only one of the three permission schemes I have any understanding of whatsoever has been unix, and even then I don't know what some of the letters stand for (r, w, x I know). That's an additional handicap.

A while back I tried to work a different issue, involving making files on an SMB share modifiable, but not deletable, on a windows box. I thought I had the information needed to get that to work, but attempts to set the permissions from the windows box (which, after all is how I'm supposed to do it) basically did not-a-damned-thing except maybe work half-assedly once, and I eventually threw my hands up in the air and just gave up.

Now all I want to do is chmod a damn file and I can't do that either.

A possible (untested) alternative to sorting this out via the client side is to (a) share the data via NFS and chmod/chown those 700 files as required( see edit below), then (b) create a new “windows share type” dataset on FreeNAS to be shared by SMB with default settings apart from setting the required owner/group. With both shares mounted on your linux client, move the files from the NFS share to the Windows share. Then check file perms on new dataset on FreeNAS, and check if your app can access the data on the SMB mount.

"with default settings apart from setting the required owner/group"

What does this mean?

FYI: I tested changing the "share type" of a dataset from uinx to windows via the WebUi in FreeNAs 11.2-U7 and the aclmode is not correclty changed from passthrough to restricted, so that looks like a bug.

Yes, and it appears that the .windows marker file doesn't get created either.

EDIT: I'm assuming you want a consistent owner/group ofr this data, and you will use std linux perms given by umask 0022, i.e 0755 dir 0644 files.

That would be a bad assumption; I believe I've mentioned the files must be 766 (as seen by the client) to work. I haven't figured out WHAT about this app imposes that requirement; but from experimenting, I know it will give me a permission denied popup even on a file I own, unless I give the world read/write.

[EDIT: This may all be moot. Suddenly I'm unable, to navigate in the app's file open dialog, to the Samba Share at all. the path is /run/user/1000/gvfs/smbv-share:server=freenas.local,share=sharename/ and "gvfs" isn't recognized as a directory at all now for some reason; I can't open it from within the select dialog at all. On the command line, it IS shown as a directory but there's no write access. This may have something to do with going back to restricted.]

At this point, all I can do is to change the share type of the data set back and forth from Samba to NFS. It's the only thing that even halfway works.

 

[KrisBee]

I had asked in my original reply how you mounted your share in Ubuntu, but I failed to pay proper attention to your answer. The “EDIT” in your last post reminded me about the “gvfs” helper programs the Ubuntu file manger uses in the background. This is the reason for you seeing “700” perms (rwx------ ) in Ubuntu (Other linux distros with other file mangers can present the perms differently). If you mount your share in Ubuntu at the CLI instead, then you will see the perms are shown differently.

Here’s an example of mounting a FreeNAS windows share called “winshare” at IP 192.168.0.111, firstly using the file manager by typing “smb://192.168.0.111” (see perms1) and secondly via the CLI, explicitly mounting the share in the users home directory( see perms2). You see the same set of files but in the second case right clicking allows to you to view dir/file permission, whereas you cannot in the first case.

Viewing the “winshare” data by opening a terminal while in the file manager shows the “700” perms, but viewing the same data in a terminal opened at the mountpoint “/home/chris/CIFS” shows “755” perms (see perms 3 – lower portion also shows the mount commands used)

In my example data prefixed “win” was created from a windows 10 client, data prefixed “lin” was created from a linux client. So, what does this look like on FreeNAS? Pic perms5 shows the data as viewed in the FreeNAS shell. Note the “+” symbol at the end perms in the listing, this indicates ACLs are in use, which can be viewed using the “getfacl” command. The file “nfstest” was moved from an “unix share type” dataset to the “windows share type” on FreeNAS via the shell. As the copy was done as “root”, the data is inconsistent until the owner is changed, but it could still be accessed by user “chris” in Windows by virtue of the “group” perms on the file.

All the above is based on FreeNAS default settings and hopefully might clarify a few things. So what about your “funky app”- what is it? Does it really need “world” access in Linux to work? I wouldn’t expect that if the app has been installed from the Ubuntu repos and is designed to run on linux. Can your app read/write files owned by your non-root user with 755/644 perms when the files are stored locally on Ubuntu?

 

[stevecyb]

I haven't had time to process your entire reply, but I'll answer this at the end.

So what about your “funky app”- what is it? Does it really need “world” access in Linux to work? I wouldn’t expect that if the app has been installed from the Ubuntu repos and is designed to run on linux. Can your app read/write files owned by your non-root user with 755/644 perms when the files are stored locally on Ubuntu?

The funky app is Veracrypt. I want to be able to access files in a veracrypt container on both kinds of system. (Not at the same time!) Because I can't get veracrypt containers in a Samba share to even open when I am on a Linux box, I have to do some very clunky things when I want to do something on a linux system with my files, like create a "transfer" container, put the files I need to work on into the container, then "mv"-move it from my SMB share dataset to an NFS share dataset at the NAS command line, then reverse the process when I'm done. When I'd much rather leave the files in their home container and access it on either system. Very annoying. It would actually be easier to use a thumb drive, but the point of a NAS is to not have to do that.

So hopefully I'll have some success with the other info in your post.

 

[KrisBee]

OK, did a quick test. Never used veracypt before but installed it on Win10. Created a vercypt conatiner formatted as NTFS with a few files added in windows10 and saved the created container to a FreeNAS SMB share.

In an Ubuntu 18 VM, installed veracrypt. Accessed FreeNAS SMB share via Ubunutu file manager typing "smb://...." This produces the errror message shown in attached "vc1.jpeg" when attempting to mount the veracrypt container in Ubuntu. A quick google leads to this, for example, https://github.com/veracrypt/VeraCrypt/issues/23

The solution is to use an explicit CIFS mount command as I showed in my last post above, e.g:

mount -t cifs -o user=chris,uid=1000,gid=1000 //192.168.0.111/winshare /home/chris/CIFS

Mounting the veracrypt container in Ubuntu now works as shown in attached "v2.jpeg"

 

[stevecyb]

OK, did a quick test. Never used veracypt before but installed it on Win10. Created a vercypt conatiner formatted as NTFS with a few files added in windows10 and saved the created container to a FreeNAS SMB share.

In an Ubuntu 18 VM, installed veracrypt. Accessed FreeNAS SMB share via Ubunutu file manager typing "smb://...." This produces the errror message shown in attached "vc1.jpeg" when attempting to mount the veracrypt container in Ubuntu. A quick google leads to this, for example, https://github.com/veracrypt/VeraCrypt/issues/23

The solution is to use an explicit CIFS mount command as I showed in my last post above, e.g:

mount -t cifs -o user=chris,uid=1000,gid=1000 //192.168.0.111/winshare /home/chris/CIFS

Mounting the veracrypt container in Ubuntu now works as shown in attached "v2.jpeg"

Indeed it does!!

Not only that, but you don't have to mount it in your home directory. (It's a bit cleaner to do it outside your home area, especially if you want to actually back up your home directory to the container!)

OK, so (for my own future edification--i can find this by looking for my own posts, if I need it:):

1) create mount point. (I did this quite some time ago. It's possible it MUST be set to 755 with myself the owner for this work; at least, that's what it is set to. That automatically happens if it's inside my home directory, but won't happen if I create it off of / (root directory).)

2) issue sudo mount -t cifs -o user=steve,uid=1000,gid=1000 //192.168.0.111/dataset /mountpoint

Note: Obviously, substitute the correct username, IP address, mount point name, AND the name of the dataset. Do not use "/mnt/poolname/datasetname" just the dataset path (presumably if you nest datasets, e.g., /dataset/nesteddataset, you'd need to specify that full path rather than just nesteddataset? Well, I doubt that I will ever need to, meanwhile, if I do try to mount a nested dataset down the road, at least I have a marker here to tell me what might go wrong).

3) sudo umount /mountpouiint will unmount it.

Note that even though file permissions are 755 (and I still can't change them), Veryacrypt works (so who cares if I can't change them?). So I suspect part of the problem was that even though user names and group ids appeared to match (mine and the ones shown in the share, and yes I even checked the uids), it probably wasn't truly registering as a match to the file system, hence the need for world write access.

ANYHOW...I believe we can mark this solved!

Thank you for your patience!

[EDIT to anyone happening on this, you may have to install support for cifs.]