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
