Yes, it does. You can make your Windows user directly a member
of local Backup Operators groups and you don't need to have any
idmap rules if not required:
# smbadm add-member -m <domain/username> "backup operators"
Note that currently only users can be a member of local groups.
Afshin
Ross Smith wrote:
No, it won't be file permissions based. I've already granted full
permissions at the file and folder level.
I was wondering if Solaris had something like the windows 'Backup
Operators' group that grants more permissions than you can assign at
the file system level.
On Fri, Jun 19, 2009 at 6:31 PM, Mark
Shellenbaum<[email protected]> wrote:
Ross Smith wrote:
Oh of course! Sorry, I'm not used to having systems that aren't full
domain members, my brain's gotten lazy.
This user has full rights in windows - they're a domain admin, but
they're not setup as any particular user on the Solaris system.
What do I need to do to grant permissions to a windows ephermial user?
Or is there a way to grant permissions to an entire windows group
like "domain admins"?
You should be able to do something like this
chmod A+usersid:j...@domain:<whatever_perms>:alllow file
chmod A+groupsid:gr...@doamin:<whatever perms>:allow file
You can also specify the SID string in place of the windows name
chmod A+usersid:S-1-5-3:<perms>:allow file
For granting rights to just one user, is it a case of:
1. Create the new user
2. Create a single user mapping with:
idmap add winuser:usern...@domain-name unixuser:username
3. Use the Solaris Users & Groups GUI tool to add that user to the
appropriate groups
Ross
On Fri, Jun 19, 2009 at 5:23 PM, Afshin Salek<[email protected]>
wrote:
Does the user who performs the operation have enough
permissions/privileges to do the operation successfully?
like restore privilege?
A network trace using /SEC and /B for a similar file for
comparison would be useful.
Afshin
Ross wrote:
Hi guys,
I first raised this back in July 2008 on snv_99, but I was very new to
Solaris at the time, and don't know if I ever filed a bug. I've just
had an
email though from somebody asking if I ever found a fix, which has
reminded
me to have a look at it again.
I'm currently running sxce_114. Ordinary use of CIFS is fine, it's
joined
to our domain, and I have no problem with permissions.
However, if I attempt to use robocopy with the /B option to transfer a
directory and keep permissions and dates intact, I get the error: "The
access control list (ACL) structure is invalid.". The copied files
transfer
ok, but permission details are lost, the files just inherit the
permissions
of the folder they are copied to.
Strangely, using robocopy with just the /SEC option works fine, and
robocopy sets all the permissions correctly.
Having done further testing today, I can confirm that this error only
happens with robocopy's /B (backup mode) switch. I remember in the past
there being talk of known problems with backup programs, was that ever
fixed?
This is potentially going to be a big problem in our migration from
Windows to Solaris CIFS servers as we use date stamps for identifying
files
to archive, and the /B switch is required if you wish to preserve these.
Ross
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
_______________________________________________
cifs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
