- carpark
- Medlem ●
- San Francisco
Hej,
för ett par månader sedan fick vi på kontoret nya MacPros (senaste varianten), vi har fått hjälp av tekniker att få allt att funka och med nät och backup.
När en av dessa tekniker var här förra veckan så hände sedan något med behörigheterna på datorn, plötsligt är det behörighetsproblem med alla filer överförda från tidigare G5an och filer skapade innan detta besöket.
Behörighetsproblemen gör att vi inte kan radera dessa filer utan att varje gång skriva in användarens lösenord, att vi då ej heller kan spara tex tidigare Ps-filer utan att spara-som och döpa om filen.
Teknikern hävdar att detta är ett problem som inom några veckor ändå hade inträffat vad han än hade gjort, att det är ett problem som inträffar alla Leopard-användare som köpt en ny dator och överfört data från sin tidigare dator (som man gör med Leopards hjälp när man först startar den nya datorn).
Tydligen har problemet något att göra med att en okänd användare skapats på datorn, en användare som man inte kan bli av med.
Stämmer något av detta? Vi är frustrerade över problemet och jag har inte hört någon annan som upplever något liknande...
Nej, så ska det inte vara.
Teknikern hävdar att detta är ett problem som inom några veckor ändå hade inträffat vad han än hade gjort, att det är ett problem som inträffar alla Leopard-användare som köpt en ny dator och överfört data från sin tidigare dator (som man gör med Leopards hjälp när man först startar den nya datorn).
Teknikern pratar strunt. Jag har ingen lösning på problemet, men jag vet att teknikern pratar strunt. Säker minst en miljon människor har gjort emigrering utan problem. Jag har gjort det på 8 nya burkar.
Har du alla filer på samma ställe så kan du rätt enkelt ändra ägare på dom i terminalen (brukar fungera si och så att göra det i findern.)
Kommandot du använder är chown, tex: sudo chown -R johan:users gammlafiler/*
Du kan kolla innan vad en vanlig nyskapad fil har för ägare med "ls -la"
Tyckte mig känna igen problemet med en "okänd" användare från någonstans... Macfixit har en artikel om detta som tyvärr inte är publik men hursomhelst så är det någon som gjort ett Bash script som sägs lösa detta problem.
Länk till Macfixit:
Mac OS X 10.5.x Special Report: Permissions problems (general) - MacFixIt
Länk till Bash scriptet:
http://homepage.mac.com/slahteine/.Public/OSS%20Built%20for%20Mac%20OS%20X/leopard-user-fix.sh.zip
Som ser ut så här:
#!/bin/bash # # Leopard User Fix by Thinkyhead # # Fixes the broken group membership in Leopard after an upgrade # if [ `whoami` == "root" ]; then echo "[ERROR] `basename $0` must be executed as an admin user (no sudo)." exit 1 fi GID_IS_UID=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep "$UID"` GID_IS_STAFF=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep 20` if [ -z $GID_IS_UID ]; then echo "[ERROR] It looks like your account is already fixed!" if [ -z "$GID_IS_STAFF" ]; then echo "[ERROR] However, you are not a member of group 'staff' which is bad!" fi echo -n "Would you like to proceed anyway? (y/N):"; read PROCEED if [ -z $PROCEED ] || [ "$PROCEED" = "n" ] || [ "$PROCEED" = "N" ]; then exit 0 fi fi # # 1. Change User's primary group to "staff" (20): # sudo dscl . changei /Users/$USER PrimaryGroupID 1 20 # # 2. Make sure the user is in the "staff" group in Directory Services: # USER_IS_IN_STAFF=`sudo dscl . read /Groups/staff | grep GroupMembership | grep "$USER"` if [ -z $USER_IS_IN_STAFF ]; then sudo dscl . append /Groups/staff GroupMembership $USER fi # # 3. Fix group permissions on all items in the user's home folder: # sudo chgrp -R staff $HOME # # ...or more slowly, but more accurately: # # sudo chgrp staff $HOME # sudo find $HOME -group $UID -exec chgrp staff "{}" \; # # ...or if you're a mad admin with files all over: # sudo find / -group $UID -exec chgrp staff "{}" \; # # # 4. Delete the group that's no longer in use: # sudo dscl . delete /Groups/$USER >/dev/null 2>&1 # # 5. Repair Permissions # echo -n "Would you like to repair permissions? (Y/n):"; read REPAIR if [ -z $REPAIR ] || [ "$REPAIR" = "y" ] || [ "$REPAIR" = "Y" ]; then sudo diskutil repairPermissions / fi # # 6. Reboot for safety. # echo -n "Logging out is recommended, but reboot is more thorough.\nWould you like to reboot? (Y/n):"; read REBOOT if [ -z $REBOOT ] || [ "$REBOOT" = "y" ] || [ "$REBOOT" = "Y" ]; then reboot fi exit 0
Teknikern tipsade om följande:
"Öppna /Program/Verktygsprogram/Terminal
Kopiera texten nedan
chmod -R ugo=rwx /Users/gustaf"
Misstänker att det är samma tips som skrivits om tidigare, iaf det funkade inte.
Sen testade han Bash-scriptet på sin egen dator vilket fuckade upp den helt (fråga mig inte hur) men han lyckades ordna tillbaka det (med andra ord han vill inte testa det på våra datorer)....
detta är så skumt, jag undrar verkligen vad han gjorde den dagen vi började få problemen....
Vad teknikern gjort är att ge fulla rättigheter för alla i världen till allt i din hemkatalog på din dator. Bad thing™.
Mitt råd är att starta upp från en Leopard installations DVD och använda verktyget "Reset Password" (minns inte vad det heter på svenska). I det verktyget finns en funktion för att rätta till rättigheter på en användare hemkatalog. Det är alltså bara den funktionen du skall använda.
Ett fel jag sett är att man lyckas få igång ACL, Access Control Lists. Ett system av rättigheter som ligger "ovanpå" unix-rättigheterna.
Problemet visade sig som att t.ex. iPhoto inte kunde ta bort bilder trots att man kunde klart se att rätt användare var ägare.
Om man skrev ls -la i terminalen så såg det rätt ut förut om en liten, liten detalj: det står ett +-tecken efter rwxrwxrwx. En ls -lae visade att ACLen sa att _ingen_ hade skrivrättigheter till alla mappar i hans hemkatalog och tydligen går ACL för unix så därför kunde han inte skriva till sina filer trots att han var ägare.
Kolla alltså en ls -la och titta efter +-tecknet, det kan vara det som spökar.
Kör man Skivverktyg så kan den säga något om "ACL found but not expected on "mappen"".
Ett fel jag sett är att man lyckas få igång ACL, Access Control Lists. Ett system av rättigheter som ligger "ovanpå" unix-rättigheterna.
Problemet visade sig som att t.ex. iPhoto inte kunde ta bort bilder trots att man kunde klart se att rätt användare var ägare.
Om man skrev ls -la i terminalen så såg det rätt ut förut om en liten, liten detalj: det står ett +-tecken efter rwxrwxrwx. En ls -lae visade att ACLen sa att _ingen_ hade skrivrättigheter till alla mappar i hans hemkatalog och tydligen går ACL för unix så därför kunde han inte skriva till sina filer trots att han var ägare.
Kolla alltså en ls -la och titta efter +-tecknet, det kan vara det som spökar.
Kör man Skivverktyg så kan den säga något om "ACL found but not expected on "mappen"".
Det stämmer att ACL är aktivt i Leopard, men det är inget man som användare råkar få igång själv, det är aktivt från början och används på ett flertal filer och mappar genom hela systemet, även i User-katalogen.
Uppdatering i frågan: fick en ny tekniker på MacSupport som hjälpte oss väldigt bra. Enda lösningen att få bort den okända användaren verkar (som det ser ut nu) att formatera om och installera systemet om från scratch. Dock gjorde löste sig problemen genom att teknikern kopierade hemmpappen till en extern disk (som då "nollställer" rättigheterna), och sen kopieras den mappen tillbaka och pang! så funkar det.
Han borde veta att man efter att fört över från en dator till en annan måste öppna nyckelhanterare, dels för att importera sin gamla nyckelring dels ge de program eller alla behörighet att använda nyckelringen.
-Står i hjälp i menylisten.
-Någon har fått aldeles för mycket betalt för ingenting!:cool:
Han borde veta att man efter att fört över från en dator till en annan måste öppna nyckelhanterare, dels för att importera sin gamla nyckelring dels ge de program eller alla behörighet att använda nyckelringen.
-Står i hjälp i menylisten.
-Någon har fått aldeles för mycket betalt för ingenting!:cool:
Har jag aldrig behövt göra. Nyckelringen kommer över i alla fall och det är väl inte alltid så smart att ge "allt" behörighet hur som helst.
Man är ju lite sugen på att veta vilket företag som har den nivån på sina tekniker.
hmm tja men det är väl inte detta som gör att en okänd användare skapas och tar över behörigheter? Eller? Dont know...nu har vi en bra tekniker iaf
Det är möjligt att han är bra men han vet tydligen inte riktigt vad han sysslar med eller hur han ska lösa saker och ting. Behörighetskontroll är A och O i alla system och den finns där av ett skäl - se till att användare och program aldrig har högre behörighet än vad som är nödvändigt.
Sätter du dig då, som tekniker, framför en dator och kör ett kommando som ger alla samma rättigheter, på en för hög nivå, så är du definitivt ute och cyklar. Visst, det löser det grundläggande problemet men du slår ut hela operativsystemets säkerhet på köpet.
Det är möjligt att han är bra men han vet tydligen inte riktigt vad han sysslar med eller hur han ska lösa saker och ting. Behörighetskontroll är A och O i alla system och den finns där av ett skäl - se till att användare och program aldrig har högre behörighet än vad som är nödvändigt.
Sätter du dig då, som tekniker, framför en dator och kör ett kommando som ger alla samma rättigheter, på en för hög nivå, så är du definitivt ute och cyklar. Visst, det löser det grundläggande problemet men du slår ut hela operativsystemets säkerhet på köpet.
Bra skrivet.
Jag tror fortfarande att problemet har med att Flyttassistenten av någon anledning "skapar" en "unknown" user...
Sökning på Apple Discussion Forum efter migration + assistant + unknown + user:
Apple - Support - Discussions - Search Discussions
Sen undrar jag om det inte finns någon här på 99.se som kan förklara vad det här scriptet gör lite bättre än jag? Jag har ju som sagt bara googlat lite...
#!/bin/bash # # Leopard User Fix by Thinkyhead # # Fixes the broken group membership in Leopard after an upgrade # if [ `whoami` == "root" ]; then echo "[ERROR] `basename $0` must be executed as an admin user (no sudo)." exit 1 fi GID_IS_UID=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep "$UID"` GID_IS_STAFF=`sudo dscl . read /Users/$USER | grep PrimaryGroupID | grep 20` if [ -z $GID_IS_UID ]; then echo "[ERROR] It looks like your account is already fixed!" if [ -z "$GID_IS_STAFF" ]; then echo "[ERROR] However, you are not a member of group 'staff' which is bad!" fi echo -n "Would you like to proceed anyway? (y/N):"; read PROCEED if [ -z $PROCEED ] || [ "$PROCEED" = "n" ] || [ "$PROCEED" = "N" ]; then exit 0 fi fi # # 1. Change User's primary group to "staff" (20): # sudo dscl . changei /Users/$USER PrimaryGroupID 1 20 # # 2. Make sure the user is in the "staff" group in Directory Services: # USER_IS_IN_STAFF=`sudo dscl . read /Groups/staff | grep GroupMembership | grep "$USER"` if [ -z $USER_IS_IN_STAFF ]; then sudo dscl . append /Groups/staff GroupMembership $USER fi # # 3. Fix group permissions on all items in the user's home folder: # sudo chgrp -R staff $HOME # # ...or more slowly, but more accurately: # # sudo chgrp staff $HOME # sudo find $HOME -group $UID -exec chgrp staff "{}" \; # # ...or if you're a mad admin with files all over: # sudo find / -group $UID -exec chgrp staff "{}" \; # # # 4. Delete the group that's no longer in use: # sudo dscl . delete /Groups/$USER >/dev/null 2>&1 # # 5. Repair Permissions # echo -n "Would you like to repair permissions? (Y/n):"; read REPAIR if [ -z $REPAIR ] || [ "$REPAIR" = "y" ] || [ "$REPAIR" = "Y" ]; then sudo diskutil repairPermissions / fi # # 6. Reboot for safety. # echo -n "Logging out is recommended, but reboot is more thorough.\nWould you like to reboot? (Y/n):"; read REBOOT if [ -z $REBOOT ] || [ "$REBOOT" = "y" ] || [ "$REBOOT" = "Y" ]; then reboot fi exit 0