Project

General

Profile

Bug #26431

Upgrade from 9.10.2-U4 to 11.0-U4 - Issue with Group Permissions on Samba Share with rsync task

Added by Benjamin Gilles almost 3 years ago. Updated almost 3 years ago.

Status:
Closed: Insufficient Info
Priority:
No priority
Assignee:
John Hixson
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:

FreeNAS 11.0-U4 Stable
Supermicro X10SL7-F with XEON E3-1231v3
2*8GB Crucial ECC 1.35V DDR3 1600MHz
4 x WD30EFRX WD Red 3TB in RAIDZ2
2 x WD Blue 1TB Drives in Mirror
Boot Device - 2 x Toshiba SSD's
EVGA 650w Modular Power Supply

ChangeLog Required:
No

Description

Prior to the upgrade, had 4 data sets, 2 of which were limited access to a particular user and group. There is a specific rsync user used to sync these datasets to another system.

After the upgrade the rsync task would not run to completion with a permission error for the 2 datasets with the limited access. Upon further investigation I found that on all my SMB shares I could no longer manage the permissions on these through the Windows dialogue box as it would just throw an error (see link to forums post with screenshot details).

Since the upgrade, I have been able to restore the ability to change permissions on one of the shares, but there is still an issue with the rsync user not having permissions to complete the rsync task, although the user can map a share in windows and have full control over the share from windows. The same user can also edit files directly from the FreeNAS command line and modify, create and delete files, but apparently not able to complete the rsync task.

It is also extremely interesting that the rsync user is not able to complete it's task with just the group permissions, for if I add the rsync user through the windows dialogue specifically with just read and List Directory permissions, the rsync process will run without error, but this is a more restrictive addition than what is previously granted via the group.

I have only been working with one share thus far to try and resolve this and would like some input as well on if the procedure I am following it the correct one to restore the ability to modify windows permissions going forward as I am still experiencing the unable to change permissions problem on the SMB shares on 2 of the remaining 4 shares, as the 2 remaining shares experiencing the issue are much larger shares, and would like validation on the correct path to resolution prior to completing this on these 2.

Please see the details in the link below, I will gladly work with anyone on this issue to get me operational again and also to prevent this from happening to someone else.

https://forums.freenas.org/index.php?threads/issue-with-cifs-permissions-after-upgrade-to-freenas-11.58789/

History

#1 Updated by Dru Lavigne almost 3 years ago

  • Status changed from Unscreened to 15

Benjamin: please attach a debug (System -> Advanced -> Save Debug).

#2 Updated by Benjamin Gilles almost 3 years ago

  • File debug-freenas-20171031121742.tgz added

Debug Attached. I don't know what kind of data is in a debug, anything I need to worry about being out here?

#3 Updated by Dru Lavigne almost 3 years ago

  • Assignee changed from Release Council to Timur Bakeyev
  • Private changed from No to Yes

Benjamin: we mark the ticket as private until the dev is finished with the debug and removes it.

#4 Updated by Benjamin Gilles almost 3 years ago

Any update on this? I am hesitant to apply any more updates from the Stable Train, until I have all the permissions sorted out on the existing shares in the correct way. I don't want to correct all the issues and then have no way to look at what happened.

#5 Updated by Benjamin Gilles almost 3 years ago

I just went back and looked at a previous ticket, and now I am curious if a previous bug has found it's way back into Version 11. The previous bug was this Bug #9899 Actually it looks to be the exact same error message on the exact same shares as far as the problem with the rsync. I am going to let the job run from the scheduled task tonight and see if it works.

That still doesn't explain why my shares that I haven't reset the permissions on, I can't adjust the permissions from windows after the upgrade.

#6 Updated by Benjamin Gilles almost 3 years ago

Can confirm that the scheduled version of the task runs correctly without a permission issue, while the Run Now version of the task has a permission problem. This is the exact same as the prior bug.

Does not resolve the inability to change permissions on CIFS share from a windows client after the upgrade though.

#7 Updated by Andrew Walker almost 3 years ago

Benjamin Gilles wrote:

Can confirm that the scheduled version of the task runs correctly without a permission issue, while the Run Now version of the task has a permission problem. This is the exact same as the prior bug.

Does not resolve the inability to change permissions on CIFS share from a windows client after the upgrade though.

Hello Benjamin,

It's possible that your rsync task is trying to chmod inside your SMB share, which is disallowed on "windows" datasets. Try the rsync option --no-perms after resetting permissions to an appropriate state.

#8 Updated by Dru Lavigne almost 3 years ago

  • Target version set to 11.1

#9 Updated by Dru Lavigne almost 3 years ago

  • File deleted (debug-freenas-20171031121742.tgz)

#10 Updated by Dru Lavigne almost 3 years ago

  • Status changed from 15 to Closed: Behaves correctly
  • Target version changed from 11.1 to N/A
  • Private changed from Yes to No

#11 Updated by Benjamin Gilles almost 3 years ago

I do not believe that this is a permissions issue on the task. Like I said in a previous comment. This bug is identical to the one that was fixed under previous bug ticket 9899 in another version.

The task is identical in both the Run Now version from the GUI, as it is when it runs via the schedule in the middle of the night. There is something different about the call that is made when using the "Run Now" option of the task from the GUI, identical to the previous bug.

This is the quote from the previous ticket that states that there was a change made to correct this issue in the prior version.

William Grzybowski wrote:

Yes, this was addressed in this ticket as well but it didn't make to the changelog as I wanted to make sure the issue was resolved before closing the ticket.

Feel free to reopen this if you see the issues again.

Thanks.

#12 Updated by Dru Lavigne almost 3 years ago

  • Status changed from Closed: Behaves correctly to Unscreened
  • Assignee changed from Timur Bakeyev to John Hixson
  • Target version deleted (N/A)

John: can you double-check this call in the middlware?

#13 Updated by John Hixson almost 3 years ago

  • Status changed from Unscreened to Screened
  • Target version set to 11.1

#14 Avatar?id=14398&size=24x24 Updated by Kris Moore almost 3 years ago

  • Target version changed from 11.1 to 11.1-U1

#15 Updated by Dru Lavigne almost 3 years ago

  • Status changed from Screened to 15

Benjamin: is this still an issue after updating to 11.1? If so, please attach a debug from the updated system.

#16 Updated by Dru Lavigne almost 3 years ago

  • Status changed from 15 to Closed: Insufficient Info
  • Target version changed from 11.1-U1 to N/A

Benjamin: closing out. If it is still an issue with 11.1, please attach a debug from the updated system to this ticket.

Also available in: Atom PDF