Permissions not persisting

[M H]

One last question, I hope. Previously, my freenas users, but not groups, would be able to be found when adding a new user in Windows permissions. Now, neither works, it will not find any additional user that I try to add. The existing users, and groups, show up and I can remove them, but I cannot add anything.

Is there any way, to set the default permissions for new files in a folder?

We have a copier that will scan PDFs to the NAS. Previously, I had a copier user set up that had access to each user's secured "scans" folder. The user would have read/write access to their scans folder and the copier would drop their PDF in their folder. Now, with Windows ACLs, the PDF owner is set to copier and the user cannot see the PDF even though IT IS in there folder (I know, because I can see them there with the root user)

 

[M H]

I think that I'm definitely having issue with DOS attributes making files read-only. I run a getfacl on a file that is "read-only" even to root and I get the follow which seems like root has all the access it needs.

But I cannot change it to writable in any way. I want to find a nice wall to bang my head against.

I try to untick the "Read-Only" option on the file in Windows and get the following:

I know that you said I should "apply default permissions," but I simply cannot spend the time to reset all the permissions again right now and the majority of files are fine.

 

[anodos]

One last question, I hope. Previously, my freenas users, but not groups, would be able to be found when adding a new user in Windows permissions. Now, neither works, it will not find any additional user that I try to add. The existing users, and groups, show up and I can remove them, but I cannot add anything.

Windows ACLs rely on SIDs mapping properly to users/groups on the FreeNAS server. There were some problems in 9.2.x post 9.2.1.6 with samba's group mapping. This issue affected some users who upgraded from 9.2.1.x to 9.3. You can see whether you're affected by checking permissions in "File Explorer" if you see SIDs instead of user / group names, then you have problems. Another thing to check are you winbind logs /var/log/samba4/log.wb*.
If you have error messages along the lines of "cannot convert SID to RID", then you'll need to nuke your group mappings and let
Otherwise, they're probably not visible because you need to cycle the CIFS service.

Is there any way, to set the default permissions for new files in a folder?

new files inherit their permissions from the ACL that you set on the share itself.

We have a copier that will scan PDFs to the NAS. Previously, I had a copier user set up that had access to each user's secured "scans" folder. The user would have read/write access to their scans folder and the copier would drop their PDF in their folder. Now, with Windows ACLs, the PDF owner is set to copier and the user cannot see the PDF even though IT IS in there folder (I know, because I can see them there with the root user)

When a user does not have 'read' access to a file, then it does not appear in Explorer.

 

[M H]

Windows ACLs rely on SIDs mapping properly to users/groups on the FreeNAS server. There were some problems in 9.2.x post 9.2.1.6 with samba's group mapping. This issue affected some users who upgraded from 9.2.1.x to 9.3. You can see whether you're affected by checking permissions in "File Explorer" if you see SIDs instead of user / group names, then you have problems. Another thing to check are you winbind logs /var/log/samba4/log.wb*.
If you have error messages along the lines of "cannot convert SID to RID", then you'll need to nuke your group mappings and let
Otherwise, they're probably not visible because you need to cycle the CIFS service.

new files inherit their permissions from the ACL that you set on the share itself.


When a user does not have 'read' access to a file, then it does not appear in Explorer.

I am getting some cannot convert SID to RID. I'm exactly in the demographic of users with issues. How do I nuke the group mappings? I looks like you meant to type something additonal there.

So, how do I allow a second user read access to a new file that the "copier" user created? The user does have read access to the folder, but the file itself does not.

 

[anodos]

I think that I'm definitely having issue with DOS attributes making files read-only. I run a getfacl on a file that is "read-only" even to root and I get the follow which seems like root has all the access it needs.

But I cannot change it to writable in any way. I want to find a nice wall to bang my head against.

I try to untick the "Read-Only" option on the file in Windows and get the following:

I know that you said I should "apply default permissions," but I simply cannot spend the time to reset all the permissions again right now and the majority of files are fine.

You will need to go through the 'apply default permissions' dance to fix this stuff. I'd try to power through the day, then fix permissions after hours. Did you try disabling DOS attributes?

 

[M H]

You will need to go through the 'apply default permissions' dance to fix this stuff. I'd try to power through the day, then fix permissions after hours. Did you try disabling DOS attributes?

I haven't added the attributes yet because I didn't want to cycle the CIFS service right now.

I DID use winacl to remove the DOSATTRIB EA and the file is no longer read-only, so it does seem related to the DOS attributes. Is there any downside to leaving the attributes disabled in config?

Thank you for your time and patience.

 

[anodos]

I haven't added the attributes yet because I didn't want to cycle the CIFS service right now.

I DID use winacl to remove the DOSATTRIB EA and the file is no longer read-only, so it does seem related to the DOS attributes. Is there any downside to leaving the attributes disabled in config?

Thank you for your time and patience.

I haven't seen a downside to disabling them.

 

[M H]

Getting alot of these errors in my shell log:

Jan 15 11:25:29 gfpnas winbindd[13098]: sam_rids_to_names: possible deadlock - trying to lookup SID S-1-5-21-2141584732-791832163-3152186724

 

[M H]

Added attributes to CIFS service and NO MORE READ-ONLY files. You are amazing!

Now, if I can just resolve my user and group recognition issue? and a way to have a user drop new files into a folder that other users can view.

 

[M H]

So cycling the CIFS service made the users "findable," but groups are still a NO. Again, my reading indicates that I have to set up group mapping somehow?

 

[M H]

So, I checked some of the permissions on old scanned files and they behave as I would expect. The scanner would use the user "copier" to place the PDF in the users folder with the user as the owner and "copier" as the group (I have both a user and group called "copier"). Everything worked great this way.

Now, with Windows ACLs, its creating the PDF with copier for both the user and group. So even though the folder has "read" access for the user, new files do not. For now, I've been manually adding "read" permissions to the file for that user, but what am I missing here. I can't make them all part of the copier group, because they would be able to see each other's files.

Make sure that in your next post, you include a PayPal donation link :)

 

[anodos]

I am getting some cannot convert SID to RID. I'm exactly in the demographic of users with issues. How do I nuke the group mappings? I looks like you meant to type something additonal there.

This is an after-hours procedure. It is kind of messy and I need to look up the steps and verify them before posting.

So, how do I allow a second user read access to a new file that the "copier" user created? The user does have read access to the folder, but the file itself does not.

I'd do it as follows:

• Apply default permissions on share with root:wheel. This results in @owner and @group having "full control", and the everyone ACE having RO access. Then I modify the everyone ACE so that it applies to "this folder only".
• Add an ACE for the scanner user granting read, write, modify access
• create your user folders, and then use the CLI to chown the folders so that they're owned by the appropriate user.

This will make it so that each user has a private folder in the share and can't see other user's folders.

 

[M H]

You are a CIFS permissions guru. I eagerly await your SID to RID instructions. Please send or PM me a PayPal link so that I can at least buy you a drink.

 

[anodos]

You are a CIFS permissions guru. I eagerly await your SID to RID instructions. Please send or PM me a PayPal link so that I can at least buy you a drink.

The instructions for this used to be

Code:

DO NOT EXECUTE
#service samba_server stop
#rm -rf /var/db/samba4/*
#rm -rf /var/etc/private*
#net groupmap cleanup
#service ix-pre-samba start
#service samba_server start

but I think that enough has changed in FreeNAS since that time that I wouldn't trust that series of commands. Try the following:

Code:

service samba_server stop
net groupmap cleanup
service ix-pre-samba
service samba_server start

Once you've executed those commands I'd try cycling the CIFS button in the webgui an extra time for good measure.

 

[M H]

Ok, I'm going to wait for a more opportune time to try to fix my group issues and report back. The day started as a huge step backward, but thanks to you, we've taken a huge step forward. Thanks. ...... (send me paypal address :))

 

[anodos]

Ok, I'm going to wait for a more opportune time to try to fix my group issues and report back. The day started as a huge step backward, but thanks to you, we've taken a huge step forward. Thanks. ...... (send me paypal address :))

Hope it goes well for you. As far as beer money goes - pay it forward. There are plenty of great projects out there that could use more beer.

 

[M H]

Hope it goes well for you. As far as beer money goes - pay it forward. There are plenty of great projects out there that could use more beer.

So I'm still holding off on running the last set of commands, but in my quest to understand everything further. I can across this line:

Code:

/usr/local/bin/net groupmap add ntgroup="ShareUsers" unixgroup=shareusers type=d rid=512

To map my unix groups to available groups in Windows. Now, I'm not sure how destructive this command is, would this be something to run?

 

[M H]

Ok, so everything has greatly improved over the last 2 weeks. I'm now running into an issue with two users. I will add the user to the security tab by looking up their name, their name is recognized correctly from the server and the new user shows on the security list. However, as soon as I click OK, that user becomes "Unknown Account" with a SID number. This happens every time, even lets say the Unknown Account is already there for the user I want to add, and I add him again, it will combine both rules under the Unknown Account.

Any ideas? Everything else seems to be living happily, including being able to find group names in the Windows GUI.

 

[RichTJ99]

I dont have any help but think i am in the same situation. The "everyone" group is added to each shared CIFS & if I delete it it comes back later, again exposing all data. My usernames in the windows share show up as a numerical combination but on a test VM it seems to work fine.

I was never on 9.2 only 9.3. I did a freenas reinstall (left the pool alone) and am having issues.

The plus side for me is that i have only 2 users, and 2 groups.

I have two pools and am tempted to:

Copy the data from my main pool to my backup pool, destroy the main pool, recreate the pool & start from scratch, then copy files from the backup pool onto the main pool.

I also was using unix shares because it was the default & it just worked.

 

[M H]

I have finally fixed the remainder of my issues. It seems that two users insisted on using SIDs from some other installation. I would go to add the user's new SID and then it would combine them under the old SID for some reason and deny access. Went ahead and deleted the account, recreated it with the same account name, but different User ID number and all is well. All my groups show up, as well as, my users.

As for Rich's question, make sure that all of your shares are set to Windows. Or "restricted" as was discussed earlier in this thread. That was the first step to getting the permissions to behaving in a predictable way. Then reset default permissions via the GUI in share settings or via the CLI using winacl. After that, when you delete Everyone, it will stay that way.

The order that worked for me.
1. Make sure all shares are set to Windows type.
2. Reset default permissions using checkbox in GUI.
3. Uncheck and begin setting up your own permissions via a Windows machine accessing the share as root user.