Windows Vista: Dateien freigeben wie bei XP

Viele von euch kennen vielleicht noch Windows XP und können sich dunkel erinnern, dass es dort nicht besonders kompliziert war, Ordner im Netzwerk freizugeben. Das hat innerhalb von Sekunden funktioniert und ging ohne Passwortabfrage.

Während Windows XP auf Windows 2000 basiert und auf den Desktop- und vor allem Heimgebrauch getrimmt wurde, basiert Windows Vista auf Server 2003, welches ein Server-OS ist und sich auch entsprechend benimmt. Will heien: Windows erwartet normalerweise eine Anmeldung für den Zugriff auf freigegebene Ordner.

Relativ einfach ginge das mit dem von Microsoft dafür vorgesehenen Shared Documents-Ordner. Alte Windows-Hasen und Fans von Explorer-Ersetzungen (wie dem Total Commander) ist das zum Einen nicht flexibel genug und zum Anderen ist nicht trivial, wo dieser ominöse Ordner zu finden ist. Glücklicherweise gehts aber dennoch so wie aus XP gewohnt. Und wie uns Murat zeigen wird, kann dann auch ein nicht-Windows-System darauf zugreifen.

In dem Beispiel wollen wir einen Ordner, der im Wurzelverzeichnis der Festplatte C liegt, freigeben.

  1. Gehe Systemsteuerung, Netzwerk- und Freigabecenter
  2. Scrolle nach unten, suche:

    • Freigabe von Dateien >> AN
    • Kennwortgeschütztes Freigeben >> AUS
  3. Wer den öffentlichen Ordner nicht nutzen möchte, kann ihn ebenfalls dort ausschalten.
  4. Gehe zu dem freizugebenden Ordner, Rechtsklick, Freigabe. Es öffnet sich dieses übersichtliche Fenster.
  5. In der Zeile, in der der Cursor blinkt, kann ein Benutzername eingegeben werden, der zugreifen darf. Klick auf den Pfeil am Ende des Felds und es öffnen sich alle lokal verfügbaren Benutzer. Wenn für den Zielordner keine Restriktionen (Passwort-Eingabe etc.) existieren sollen, dann sollte Gast ausgewählt werden (egal, ob der Gast-Account für die Benutzeranmeldung im System aktiviert ist oder nicht)
  6. Klick auf Hinzufügen
  7. Bei Berechtigungsebene können die Rechte eingestellt werden, denen sich der ggf. angemeldete Benutzer auf dem Zielrechner unterwerfen sollen. Leser kann beispielsweise keine Daten verändern.
  8. Klick Freigabe
  9. Warte einen Moment
  10. Klick Fertig (wer auf Pfadeingaben steht, kann sich auch den Pfad merken, der einzugeben ist, den Windows freundlicherweise mit angibt)

Und schau an, sogar ein Mac OS kann nun darauf zugreifen und das ohne Eingabe eines Passworts:
dateifreigabeaufmac
(danke an siebenundsiebzig für das Bild)

Eine Freigabe wieder aufzuheben, ist etwas einfacher. Einfach Rechtsklick auf den freigegebenen Ordner, Freigabe, Freigabe beenden.

Der Host-Rechner für diese Anleitung war ein Vista Business mit SP1, die Client-Rechner waren ein MacBook mit Mac OS X 10.5.7 sowie unser aller Server mit Windows Server 2003 Enterprise Edition.
Da Mac OS X genau wie Linux auf Samba zurückgreift für Windows-Freigaben, nehme ich an, dass auch Linux in der Lage sein wird, auf diese Vista-Freigabe zugreifen zu können.

Update von Vista auf Windows 7 RC1 schlägt fehl

Hallo Microsoft!

Da ihr seit der RC1 von Windows 7 auf den netten Link Kommentare? in der Titelzeile der Fenster verzichtet, packe ich mal möglichst viele Buzzwords in den H1-Tag.

Folgendes. Ich habe versucht, Horst auf Windows 7 zu aktualisieren. Es ging dabei selbstverständlich um die 64-Bit Versionen von Vista und 7. Eine frische Installation von Windows 7 auf einer separaten Partition hat funktioniert. Das Update leider nicht.

Was ist passiert? DVD eingelegt, Setup aufgerufen, Upgrade geklickt, Windows-Updates herunterladen lassen. Setup hat die Daten gesucht und über 400000 gefunden, die es zu bearbeiten galt. Danach wurde der Kopiervorgang gestartet. Reboot. Dateien werden expandiert, Features installiert Reboot. Bis hierher waren wir bei einer guten halben Stunde angekommen, was durchaus ok ist für eine OS-Installation. Als letztes kam Dateien, Einstellungen und Programme werden übertragen da war ich sehr geduldig. Länger als 3 Stunden habe ich gesehen, dass ich nichts sehe. Keine Festplattenaktion, kein Fortschritt. Nur die drei Punkte waren weiterhin animiert. Schlielich habe ich dem Rechner den Gnadenschuss gegeben und ihn ausgeschaltet und wieder eingeschaltet.

An der Stelle nach dem Bugreport noch ein Lob denn dass Setup auf die Idee kommt, bei einem solchen Fehlversuch die alte Installation wieder herzustellen, ist schon ziemlich cool. Auch dass es funktioniert und vor allem nur 3 Minuten dauerte! stellt den Anwender nach all dem vergeblichen Warten sehr zufrieden.

Zurück im Vista wird man dann mit der folgenden netten Dialogbox begrüt:
win7-upd
Was die Dialogbox offensichtlich nicht gesehen hat, ist, dass der Update-Advisor bereits grünes Licht für ein Update auf Windows 7 gab.
So, das war mein Bugreport. Da ich eigentlich vorhabe, Windows 7 so bald es kommt einzusetzen, wünsche ich mir dass dieser Fehler bis dahin behoben ist. Denn ich bin mir noch nicht so wirklich sicher, ob ich dann Bock auf eine frische Installation habe.

Nicht nachmachen: chown -R www-data /*

$ chown -R www-data /*

Dieser nette Befehl sorgt dafür, dass unter Linux (und allen anderen Unix-artigen Systemen) alle Ordner nebst Dateien auf dem Rechner einen neuen Besitzer bekommen, in dem Fall www-data.

Wenn ihr Glück habt, bricht diese Aktion vorzeitig ab:

chown: ndern des Eigentümers von »/proc/1/task/1«: Operation not permitted
chown: ndern des Eigentümers von »/proc/1«: Operation not permitted
chown: ndern des Eigentümers von »/proc/16044/task/16044«: Operation not permitted

Aber dann ists auch schon zu spät, weil /proc recht weit hinten kommt.

Weniger schöner Nebeneffekt ist der folgende:

user@server:~$ su
Passwort:
su: Fehler bei Authentifizierung
user@server:~$

Kein root-Login mehr. Tja, shit happens.

Bevor Fragen aufkommen:

  • Nein, ich wars nicht
  • Nein, es war auch nicht mein Server
  • Aber ja, ich bin einer derjenigen, der es wieder hinbiegen muss.
  • Das was der gute Mensch hätte ausführen wollen, hätte so ausgesehen:
    chown -R www-data ./

    Also fast so ähnlich.

*sigh* – manche Leute können gerne Server bezahlen, aber root-Zugang sollten sie dann trotzdem nicht bekommen.

S.M.A.R.T. Capable and Status OK

Das sagte das BIOS beim Hochfahren von Knut.

Klack-klackklack-klack-(Pause)-klackklack – das sagte die Festplatte. Und nach dem POST wartete das BIOS gedultig darauf, dass die Festplatte vielleicht doch noch zu sich kommt. Vergebnis. Zuvor ist der Windows 2003-Server noch eingefroren. der Reboot (der nicht klappte) erklärte dann auch den Freeze. Immerhin machte der 2003 Server bis zum aller letzten Moment kompromisslos mit.

Um mal ein kleines Bisschen Statistik in die Sache zu bringen. Das war die Western Digital-Fesplatte Nr. 6 (von 7), die gestorben ist. Von diesen 6 sind 5 innerhalb der Garantie gestorben und wurden umgetauscht. Deshalb entstand der Eindruck, die umgetauschten wären weniger störanfällig. Aber heute ist die erste umgetauschte gestorben.

Dem gegenüber steht eine Seagate (von 7), die die Garantiezeit nicht überlebt haben. Hitachi sind 2 im Einsatz, davon eine getauscht und bei Samsung gibts auch 2 zu vermelden, von denen beide noch leben.

Das war die gesamte Festplattenausbeute der letzten 7 Jahre. Ich hoffe, ihr habt Verständnis dafür, dass Western Digital einen weniger guten Ruf bei uns geniet.

PS: Ein Athlon XP 2000+ mit 768 MB RAM ist _definitiv_ zu schwach für Server 2008. Oder taugt der Server 08 einfach blo (noch) nichts?

ARMer Bruno

Also. Son iPod Touch („Bruno“) hat ja nen ARM-Prozessor. ARM ist ja nun nicht Intel und auch nicht PowerPC. Ich glaube fast, dass ARM auch für OS-Schreiber etwas anders ist. Zumindest ist bei Murat noch nichts von Apple (geschweige denn der Kernel) abgestürzt. Aber bei Bruno – und es ist ja nicht das erste Mal – alleine die Ausbeute der letzten 24 Stunden.

Da hätten wir den Media-Server:

Incident Identifier: D3DFA4F4-2719-4CB9-A816-8B3F0B99EFA2
CrashReporter Key:   38815b35c9eb9e881a90798adf98a7a594a5c01e
Process:         mediaserverd [16]
Path:            /usr/sbin/mediaserverd
Identifier:      mediaserverd
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2009-03-25 23:23:53.493 +0100
OS Version:      iPhone OS 2.2.1 (5H11a)
Report Version:  103

Exception Type:  00000020
Exception Codes: 0xbe18d1ee
Highlighted Thread:  3

Application Specific Information:
mediaserverd rpc timeout

Weils so schön war, gleich nochmal:

Incident Identifier: 9F83C4EE-554B-4E2D-8545-0BC021003D19
CrashReporter Key:   38815b35c9eb9e881a90798adf98a7a594a5c01e
Process:         mediaserverd [90]
Path:            /usr/sbin/mediaserverd
Identifier:      mediaserverd
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2009-03-25 23:24:12.352 +0100
OS Version:      iPhone OS 2.2.1 (5H11a)
Report Version:  103

Exception Type:  00000020
Exception Codes: 0xbe18d1ee
Highlighted Thread:  3

Application Specific Information:
mediaserverd rpc timeout

Mal was anderes, der Safari:

Incident Identifier: 58F30D52-6D64-422D-BB81-839E16B23150
CrashReporter Key:   38815b35c9eb9e881a90798adf98a7a594a5c01e
Process:         MobileSafari [36]
Path:            /Applications/MobileSafari.app/MobileSafari
Identifier:      MobileSafari
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2009-03-26 05:56:07.829 +0100
OS Version:      iPhone OS 2.2.1 (5H11a)
Report Version:  103

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000004
Crashed Thread:  0

UND! Noch eine Kernel-Panic! DAS sollte nun wirklich nicht wegen einer Endanwendung passieren. Vor allem keiner aus dem AppStore.

Incident Identifier: F3203345-C905-4363-AD38-C0FBF2443480
CrashReporter Key:   38815b35c9eb9e881a90798adf98a7a594a5c01e
Date/Time:       2009-03-26 12:50:43.149 +0100
OS Version:      iPhone OS 2.2.1 (5H11a)

Debugger message: WDT timeout
90s ago: 5091m0 4991m0 4891m0 4791m0 4691m0 4591m0 4491m0 4391m0 4291m0 4191m0 4091m0 3991m0 3891m0 3791m0 3691m0 3591m0 3491m0 3391m0 3291m0 3191m0 3091m0 2991m0 2891m0 2791m0 2690m0 2590m0 2490m0 2390m0 2290m0 2190m0 2090m0 2069pe0000270 2068pe0000280 2068s818600 2064pe0000320 2061pe0000300 2061r818600 2060m0 1960m0 1909pe0000270 1907pe0000280 1907s818600 1903pe0000320 1900pe0000300 1900r817600 1900m0 1800m0 1700m0 1600m0 1500m0 1400m0 1300m0 1200m0 1100m0 1000m0 900m0 800m0 700m0 600m0 500m0 400m0 300m0 200m0 0m10004003
OS version: 5H11a
Kernel version: Darwin Kernel Version 9.4.1: Mon Dec  8 21:02:57 PST 2008; root:xnu-1228.7.37~4/RELEASE_ARM_S5L8720X
iBoot version: iBoot-385.49
secure boot?: YES
Paniclog version: 1
Task 0xc09f6ce8: 5769 pages, 65 threads: pid 0: kernel_task
    thread 0xe02e7100
        kernel backtrace: ec3bbae4
          lr: 0xc00670b5  fp: 0xec3bbb14
          lr: 0xc006731b  fp: 0xec3bbb2c
          lr: 0xc02a4535  fp: 0xec3bbfa8
          lr: 0xc00659f8  fp: 0x00000000

Task 0xc09f6b10: 92 pages, 3 threads: pid 1: launchd
Task 0xc09f63b0: 24 pages, 1 threads: pid 13: update
Task 0xc09f61d8: 64 pages, 4 threads: pid 14: syslogd
Task 0xc09f6588: 208 pages, 3 threads: pid 15: lockdownd
Task 0xc14aace8: 151 pages, 2 threads: pid 17: mDNSResponder
Task 0xc14aa938: 363 pages, 9 threads: pid 19: iapd
Task 0xc14aa760: 77 pages, 1 threads: pid 20: fairplayd
Task 0xc14aa588: 281 pages, 5 threads: pid 21: configd
Task 0xc14aa3b0: 1912 pages, 12 threads: pid 22: SpringBoard
Task 0xc1571ce8: 164 pages, 4 threads: pid 25: CommCenter
Task 0xc1571b10: 137 pages, 2 threads: pid 26: BTServer
Task 0xc1571938: 64 pages, 2 threads: pid 27: notifyd
Task 0xc14aa1d8: 2300 pages, 5 threads: pid 39: MobileMusicPlaye
Task 0xc09f6938: 758 pages, 4 threads: pid 77: MobileMail
Task 0xc09f6000: 821 pages, 16 threads: pid 93: mediaserverd
Task 0xc1571588: 7759 pages, 5 threads: pid 123: VWPolo

Was mich jetzt aber mal brennend interessiert. Bin ich allein damit? Kann ich mir ja fast nicht vorstellen… Aber anderen iPhone-Besitzer (die ja mit dem gleichen OS und auch im Wesentlichen gleicher Hardware auskommen müssen) ist diesbezüglich nichts aufgefallen?! Jemand ne Idee?

Wie hab ich das denn gemacht?

Also noch einmal von vorn. Wenn etwas abstürzt, dann ist es weg, oder? Also wie Bildschirm schwarz und so. Und wenn „es“ halbwegs clever ist, startet es neu.
So. Das heit also… Wenn etwas abstürzt, würde man es mitbekommen.

PREISFRAGE: Ich habe nichts mitbekommen und iTunes meinte eben zu mir, er habe was, was Apple-Produkte verbessern würde, meine Privatsphäre aber nicht verletzt. Bei Klick auf den ominösen Details-Button zeigte er mir einen Crashdump, der in etwa so aussieht:

Incident Identifier: 04D77AC8-8788-45EF-B600-E7F849BE2696
CrashReporter Key:   38815b35c9eb9e881a90798adf98a7a594a5c01e
Process:         iapd [57]
Path:            /System/Library/PrivateFrameworks/IAP.framework/Support/iapd
Identifier:      iapd
Version:         ??? (???)
Code Type:       ARM (Native)
Parent Process:  launchd [1]

Date/Time:       2009-03-17 20:07:12.995 +0100
OS Version:      iPhone OS 2.2.1 (5H11a)
Report Version:  103

Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000004
Crashed Thread:  0

Was soll das? Warum hab ich das nicht mitbekommen. UND! Wie hab ich das hingekriegt???