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
