Kategorie-Archiv: Linux

Problem

• Es soll ein CIFS share von einem Netapp Filer, einem Windows 2000 oder anderem Linux-System gemountet werden; es tritt der Fehler „mount error 13 = Permission denied“ auf.
• Einzelne (bis zu zwei) Shares können problemlos verbinden werden. Ob die Credentials an der Kommandozeile eingegeben oder aus einer Credentialsfile eingelesen werden ist egal, es tritt immer der selbe Fehler auf.
• Das sieht zum Beispiel so aus:

# mount -t cifs //exampleserver/share1 /mnt/share1 -o credentials=/root/.credentials/s1
# mount -t cifs //exampleserver/share2 /mnt/share2 -o credentials=/root/.credentials/s2
mount error 13 = Permission denied
Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

Lösung

Die Verbindungssicherheit erlaubt nur zwei Verbindungen pro Hostsitzung für einen Benutzer (=Mountpoint). In älteren Kernels wird dieses System umgagen, wenn das Ziel ein Windows 2000 ist. Netapp nutzt (im Moment) die CIFS-Version von Windows 2000, daher fehlen einige Protokollfeatures.

Möglichkeit 1: Einen älteren Kernel installieren (Redhat: vor 2.6.18-348.18.1)

Möglichkeit 2: Maximal zwei Verbindungen pro Benutzersitzung verwenden.

Referenz: https://access.redhat.com/site/solutions/509393

Einen Datenträger unter Windows im laufenden Betrieb vergrößern ist schnell erledigt. Ein bisschen umständlicher ist das bei einem Linux-Gast – hier aufgelistet am Beispiel Debian. Unsere Beispielplatte ist /dev/sdb mit einer einzigen Partition /dev/sdb1 darauf, die vergrößert werden soll.

1. Die betreffende Platte unmounten

   umount /dev/sdb

2. Die SCSI-ID herausfinden um den Bus gleich nochmal scannen zu können

    cat /proc/scsi/scsi
   Attached devices:
   Host: scsi0 Channel: 00 Id: 00 Lun: 00
   Vendor: VMware   Model: Virtual disk     Rev: 1.0
   Type:   Direct-Access                    ANSI SCSI revision: 02
   Host: scsi0 Channel: 00 Id: 01 Lun: 00
   Vendor: VMware   Model: Virtual disk     Rev: 1.0
   Type:   Direct-Access                    ANSI SCSI revision: 02
   Host: scsi0 Channel: 00 Id: 02 Lun: 00
   Vendor: VMware   Model: Virtual disk     Rev: 1.0
   Type:   Direct-Access                    ANSI SCSI revision: 02
   

   Uns geht es hier beispielhaft um:

   Host: scsi0 Channel: 00 Id: 02 Lun: 00
   Vendor: VMware   Model: Virtual disk     Rev: 1.0
   Type:   Direct-Access                    ANSI SCSI revision: 02

3. Einmal den Bus neu einlesen um die neuen Werte sehen zu können:

    echo "scsi remove-single-device 0 0 2 0" >/proc/scsi/scsi
   echo "scsi add-single-device 0 0 2 0" >/proc/scsi/scsi

   Ob die neue Größe auch tatsächlich angekommen ist prüft ein

   fdisk –l

4. Die Volumenbehandlung starten

   fdisk /dev/sdb

5. Mit **p** die aktuellen Partitionen anschauen.
6. Mit **d** die aktuelle (in unserem Fall die 1.) Partition löschen (Don’t Panic: es werden keine Daten gelöscht.)
7. Mit **n** eine neue Partition erzeugen
8. Mit **1** diese als erste erstellen (je nach Konfiguration entfällt dieser Schritt eventuell)
9. Mit **p** die Partition als „primary“ setzen
10. Mit **1** den ersten Zylinder festlegen
11. Das Ende der Partition festlegen (die vollständige Größe wird genutzt wenn man das Feld freilässt)
12. Mit **a** kann man die Partition auch noch active setzen (mit aktive Partitionen sind bootfähig)
13. Und dann mit **1** ins Menü wechseln …
14. Um mit **w** die Änderungen zu schreiben.
15. Partition mounten:

    mount /dev/sdb1 /mnt/hiersolleshin

16. Partition jetzt endlich vergrößern mit

    resize2fs /dev/xvde1

17. Partitionsgröße prüfen mit

    df –h

Fertig. Fast gar nicht umständlich. Und das im Zeitalter der allgegenwärtigen Virtualisierung.

An diesem Phänomen habe ich jetzt eine ganze Weile gebastelt – aber ich bin zufrieden mit der Lösung 🙂

Problem: Umlaute in Dateinamen werden Unter Windows anders angelegt als unter Linux (Shell/Konsole/X) und noch anders unter DOS. Einen brauchbarer Fileserver mit Umlauten in Dateinamen ist unter Samba praktisch nicht zu betrieben.

Lösung: Die meisten Phänomene mit deutschen Umlauten bekommt man in den Griff, indem man das Dateisystem weiterhin in UTF-8 betreibt (es gibt da die wildesten Anleitungen im Netz), aber die Umlaute durch Samba hart in Windows-Ansi (Codeseite 1252) schreiben lässt. Da Windows selber immer abwärtskompatibel zu DOS bleibt (die gute alte CP850), kann man 1252 in der Regel ohne Probleme zu Samba 3.0.3x (smb.conf)  hinzufügen:

[global]
unix charset = UTF-8
dos charset = cp1252

In Samba <3 lautet die Option (hier alternativ mit ISO8859-1 für Windows-ANSI):

character set = ISO8859-1

Ein schnelles

/etc/init.d/smb reload

läd die Config im laufenden Betrieb auch neu und alles ist gut.

Achtung – Bestehende Dateien werden dadurch natürlich nicht verändert. Schon geschriebene Umlaute bleiben so wirsch wie sie sind. Das gilt auch nur für den Zeichensatz CP1252, also nicht für den ganzen UTF-8 Zeichenraum. Da wird es so auch weiterhin diese lustigen Codierungsfehler geben.

Bestehende falsche Umlaute im Dateinamen nachträglich (bulk) korrigieren

In der Shell kann man solche falsch benannten Dateien natürlich einfach einzeln umbenennen; zum Beispiek mit mv (oder dem rename-alias):

mv seltsamezeichen???.txt seltsamezeichenÄÖÜ.txt

Das Fragezeichen ist hier der Platzhalter für ’nur ein Zeichen, aber jedes‘. Achtung beim Escapen von Leereichen ( ), hier habe ich mich auch schon ein paarmal „Ganz sch?n ge?rgert.txt“ weil ich einen Backslash an der falschen Stelle eingebaut hatte.

Lösung: Bulk umbenennen mit „convmv“. Das ist bei allen großen Distributionen dabei oder im Repository (warum wohl?) und funktioniert so:

convmv -f iso-8859-15 -t utf-8 --notest /foo/bar

Damit werden in /foo/bar alle Dateinamen von ISO-8859-15 nach UTF-8 konvertiert. Mit -r geht das natürlich auch rekursiv.