• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[gelöst]Schreiben auf Samba-Freigabe nicht möglich

H

halo44

Ich benötige mal wieder Nachhilfe. Diesmal in Sachen Samba. Ich komme hier einfach nicht weiter.

Die Situation ist die folgende: auf dem Rechner meiner Frau ist openSuse 13.1-64 und auch Windows 7 installiert. In Windows ist neben der Systempartition C eine Datenplatte D eingerichtet, die ich auch aus dem Suse-OS meiner Frau erreichen kann. Der Eintrag in der /etc/fstab dieses Rechners
Code: 
UUID=2D3EE464792AF028 			   /windows        ntfs-3g    users,gid=users,fmask=133,gmask=022,locale=de-DE.UTF-8  0 0
Ich kann von der Suse aus Dateien auf der Datenplatte D löschen, ändern und hinzufügen.

Von meinem Rechner mit openSuse 13.1-64 aus erreiche ich die Datenplatte D ebenfalls, kann aber nur lesend zugreifen. Das sowohl wenn auf dem Rechner meiner Frau Windows oder auch openSuse läuft. Will ich schreiben, so erhalte ich
Code: 
Zugriff verweigert.
Schreiben nicht möglich auf smb://ap-suse/FG-Windows-D/MediathekView/mp4/Film-nnn.mp4

Ich realisiere auf meinen Rechnern auch andere Zugriffe über Samba mit gleichlautender smb.conf (ausgenommen Freigabename und Path), die alle funktionieren. Allerdings ist hier nirgends Windows im Spiel.

Was mir noch auffällt: der Eigentümer der betreffenden Ordner ist "root users", was ich auch mit Rootrechten nicht ändern kann.

Kann mir bitte jemand "unter die Arme greifen"?

Danke H.
 
OP
H

halo44

Inzwischen habe ich natürlich weitere Möglichkeiten ausprobiert. So habe ich auf meinem Rechner (also dem Client) die /etc/fstab folgendermaßen angepasst :
Code: 
//ap-suse/windows			/mnt/windows-d-ap		ntfs-3g noauto,users 0 0

Auch habe ich auf dem Client dem Programm ntfs-3g das SUID-Bit verpasst :
Code: 
chmod +s /usr/bin/ntfs-3g

Jetzt stellt sich die Situation so dar, daß ich (wie auch schon vorher) alle Dateien in der Freigabe lesen kann. Ich kann auch alle löschen und neue Dateien schreiben. Allerdings kann ich keine vorhandenen Dateien überschreiben. Dies scheint zumindest mir mehr als mysteriös zu sein.

Vielleicht fällt ja doch noch jemand etwas ein.

Gruss H.
 
S

spoensche

halo44 schrieb:
Auch habe ich auf dem Client dem Programm ntfs-3g das SUID-Bit verpasst :
Code: 
chmod +s /usr/bin/ntfs-3g
Zum Vergrößern anklicken....
:schockiert:
Den Unsinn machst du mal ganz schnell wieder rückgängig.

halo44 schrieb:
Inzwischen habe ich natürlich weitere Möglichkeiten ausprobiert. So habe ich auf meinem Rechner (also dem Client) die /etc/fstab folgendermaßen angepasst :
Code: 
//ap-suse/windows			/mnt/windows-d-ap		ntfs-3g noauto,users 0 0

Jetzt stellt sich die Situation so dar, daß ich (wie auch schon vorher) alle Dateien in der Freigabe lesen kann. Ich kann auch alle löschen und neue Dateien schreiben. Allerdings kann ich keine vorhandenen Dateien überschreiben. Dies scheint zumindest mir mehr als mysteriös zu sein.
Zum Vergrößern anklicken....

:???:
Mit ntfs-3g mountet man keine Sambashares von entfernten Rechnern, sondern Partitionen mit dem NTFS Dateisystem von lokal angeschlossenen Festplatten.

Sambashares werden über das Netzwerk per CIFS (Common Internet File System) bereitgestellt und am Client mittels
Code: 
mount -t cifs ....
gemountet.

Dein Eintrag in der fstab müsste also so aussehen:
Code: 
//ap-suse/windows /mnt/windows-d-ap cifs noauto,workgroup=Eure-Arbeitsgruppe

Wenn kein Windows Client auf die Freigabe zugreift, warum verwendest du dann kein NFS?

PS:
Mit einem kurzen Blick in die man Page wärst du selbst darauf gekommen. ;)
 
OP
H

halo44

spoensche schrieb:
... Den Unsinn machst du mal ganz schnell wieder rückgängig.
Zum Vergrößern anklicken....

OK, ich hab das SUID-Bit wieder entfernt.

spoensche schrieb:
... Mit ntfs-3g mountet man keine Sambashares von entfernten Rechnern, sondern Partitionen mit dem NTFS Dateisystem von lokal angeschlossenen Festplatten.

Sambashares werden über das Netzwerk per CIFS (Common Internet File System) bereitgestellt und am Client mittels
Code: 
mount -t cifs ....
gemountet.

Dein Eintrag in der fstab müsste also so aussehen:
Code: 
//ap-suse/windows /mnt/windows-d-ap cifs noauto,workgroup=Eure-Arbeitsgruppe
Zum Vergrößern anklicken....

Hab ich so (noch mal) nach vollzogen. Sowohl mit
Code: 
sudo mount -t cifs //ap-suse/FG-Windows-D /mnt/windows-d-ap
als auch über dolphin mit
Code: 
smb://ap-suse/FG-Windows-D/
habe ich Zugriff auf die Daten.

Immer noch kann ich alle Dateien in der Freigabe lesen. Ich kann auch alle löschen und neue Dateien schreiben. Allerdings kann ich keine vorhandenen Dateien überschreiben. Genau das ist mein Problem. Der grundsätzliche (eingeschränkte) Zugriff klappt.

spoensche schrieb:
... Wenn kein Windows Client auf die Freigabe zugreift, warum verwendest du dann kein NFS? ...
Zum Vergrößern anklicken....

Recht hast Du, aber mit NFS bin ich auf den gleichen Fehler gelaufen und habe deshalb mein Glück mit Samba versucht, zumal ja die betroffene Partition vom Typ NTFS (also Windows) ist.

Der Hund muß irgendwo da begraben liegen, daß ich von einem Suse-Client auf einem Suse-Server auf eine NTFS-Partition Dateien (über)schreiben möchte.

Danke für Dein Engagement.

Gruss H.
 
OP
H

halo44

Ich habe inzwischen einen Teilerfolg erreicht, indem ich sowohl die NTFS-Partitition neu eingerichtet und den Server neu installiert und konfiguriert habe. Auch die /etc/fstab auf dem Client habe ich modifiziert.

Der Status ist jetzt der, daß ich alle Rechte auf der Freigabe habe, wenn ich über Dolphin mittels Netzwerk >> Samba-Freigaben >> Workgroup >> Server >> Freigabe-Name diese mounte. Hierzu muß ich Nutzernamen und sein Samba-Passwort eingeben.

Versuche ich das gleiche über den Mount-Befehl
Code: 
sudo mount -t cifs //ap-suse/FG-Windows-D /mnt/windows-d-ap -o username=xxx,password=yyy
wird die Freigabe ebenfalls gemountet und ich kann dort lesen und löschen, aber nicht schreiben.

Der Eintrag in der /etc/fstab des Clients
Code: 
//ap-suse/FG-Windows-D 			/mnt/windows-d-ap 		cifs 	noauto,user               0 0
Kennt sich da noch wer aus?

Übrigens will ich mich mit NFS (wo der Schreibzugriff auch scheitert) erst nach Lösung des Sambazugriffs beschäftigen. Ich möchte nicht 2 Baustellen zur gleichen Zeit betreiben.

Gruss H.
 
S

spoensche

Gib beim mounten zusätzlich noch die Optionen dmask und fmask an.

Code: 
mount -t cifs //suse-ap/windows /mnt -o username=xxx,password=xxx,dmask=777,fsmask=666
 
OP
H

halo44

Danke für die Anregung. Allerdings wollte meine Suse von mir lieber dir_mode und file_mode statt dmask und fmask haben. Diesen Wunsch habe ich ihr auch erfüllt.

Leider aber wurde die Freigabe wieder mit dem gleichen Ergebnis gemountet, d.h. Lesen, Löschen, aber kein Schreiben.

Danach habe ich beim nächsten Versuch sichergestellt, daß die numerischen User-IDs der angemeldeten Benutzern auf Server und Client identisch waren. Wieder die frustrierende Entgegnung :
Code: 
    Zugriff verweigert.
    Schreiben nicht möglich auf smb://ap-suse/FG-Windows-D/MediathekView/mp4/Film-nnn.mp4

Merkwürdig war allerdings hierbei, daß mein Suse-Client bei diesem Versuch den Pfad //ap-suse/windows nicht akzeptieren wollte. Statt dessen mußte ich den Freigabe-Namen anwenden: //ap-suse/FG-Windows-D. Merkwürdige Samba-Welt :???: .

Mir ist klar, daß ich andere Möglichkeiten habe die Dateien zu transportieren. Diese nutze ich auch derzeit. Allerdings sollte der Samba-Transfer grundsätzlich möglich sein. Das Tool ist ja nicht neu und eigentlich viel genutzt und erprobt (?).

Gruss H.
 
S

spoensche

halo44 schrieb:
Merkwürdig war allerdings hierbei, daß mein Suse-Client bei diesem Versuch den Pfad //ap-suse/windows nicht akzeptieren wollte. Statt dessen mußte ich den Freigabe-Namen anwenden: //ap-suse/FG-Windows-D. Merkwürdige Samba-Welt :???: .
Zum Vergrößern anklicken....

Wieso ist das merkwürdig? Du kannst nur auf die Freigabe zugreifen, aber nicht auf den darunter liegenden ursprünglichen Dateisystempfad. Die Freigabe representiert ja den darunter liegenden Dateisystem Pfad.

halo44 schrieb:
Mir ist klar, daß ich andere Möglichkeiten habe die Dateien zu transportieren. Diese nutze ich auch derzeit. Allerdings sollte der Samba-Transfer grundsätzlich möglich sein. Das Tool ist ja nicht neu und eigentlich viel genutzt und erprobt (?).
Zum Vergrößern anklicken....

Es gibt andere Möglichkeiten ja, aber deswegen muss man ja nicht den Kopf in den Sand stecken. ;)

Was sagen den die Samba Logs des Servers, wenn du versuchst die Freigabe zu mounten?
 
OP
H

halo44

spoensche schrieb:
... Was sagen den die Samba Logs des Servers, wenn du versuchst die Freigabe zu mounten?
Zum Vergrößern anklicken....

Erstmal vorweg : es bleibt ja nicht beim Versuch. Die Freigabe wird gemountet und ich kann lesen, löschen aber nicht schreiben. Es erfolgt die Fehlermeldung "... schreiben nicht möglich ...", wobei die Datei allerdings angelegt wird mit 0 Byte :
Code: 
-rw-r--r-- 1 root users      0 26. Sep 13:36 beispiel.txt

Doch nun zu Deiner Frage. Das Sambalog des Servers (/var/log/samba/log.smbd) zeigt nur folgende Einträge
Code: 
[2014/09/26 13:17:37,  0] ../source3/smbd/server.c:1214(main)
  smbd version 4.1.11-3.26.1-3274-SUSE-oS13.1-x86_64 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2013
[2014/09/26 13:17:37.958953,  0] ../lib/util/become_daemon.c:137(daemon_ready)
  STATUS=daemon 'smbd' finished starting up and ready to serve connections
Diese liegen 19 Minuten vor meinem Schreibversuch. Dieser schlägt sich anscheinend im Log nicht nieder.

Der Status von Samba :
Code: 
smb.service - Samba SMB Daemon
   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled)
   Active: active (running) since Fri 2014-09-26 13:17:37 CEST; 36min ago
  Process: 1061 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS)
 Main PID: 1065 (smbd)
   Status: "smbd: ready to serve connections..."
   CGroup: /system.slice/smb.service
           ├─1065 /usr/sbin/smbd -D
           ├─1068 /usr/sbin/smbd -D
           └─1716 /usr/sbin/smbd -D

Sep 26 13:17:37 ap-suse systemd[1]: Starting Samba SMB Daemon...
Sep 26 13:17:37 ap-suse smbd[1065]: [2014/09/26 13:17:37.958953,  0] ../lib/util/become_daemon.c:137(daemon_ready)
Sep 26 13:17:37 ap-suse systemd[1]: Started Samba SMB Daemon.
Sep 26 13:17:37 ap-suse smbd[1065]: STATUS=daemon 'smbd' finished starting up and ready to serve connections

Gruss H.
 
S

spoensche

halo44 schrieb:
Code: 
-rw-r--r-- 1 root users      0 26. Sep 13:36 beispiel.txt
/quote]

Da scheint etwas mit dem UID (User ID) Mapping nicht zu stimmen. Daher bekommst du auch die Meldung Permission Denied. Ist in der /var/log/warn etwas zu Samba zu finden?

Poste bitte mal die Ausgabe von
Code: 
smbclient -U dein-user -W deine-workgroup -L ip-des-samba-servers
.
Als User verwendest du bitte den gleichen wie beim mounten der Freigabe.
Zum Vergrößern anklicken....
 
OP
H

halo44

spoensche schrieb:
... Ist in der /var/log/warn etwas zu Samba zu finden? ...
Zum Vergrößern anklicken....
Nur dies hier
Code: 
2014-09-26T19:15:23.276262+02:00 ap-suse smbd[565]: [2014/09/26 19:15:23.276095,  0] ../lib/util/become_daemon.c:137(daemon_ready)
2014-09-26T19:15:23.277023+02:00 ap-suse smbd[565]:   STATUS=daemon 'smbd' finished starting up and ready to serve connections

spoensche schrieb:
... Poste bitte mal die Ausgabe von
Code: 
smbclient -U dein-user -W deine-workgroup -L ip-des-samba-servers
Zum Vergrößern anklicken....
Dies zeigt mir das
Code: 
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.11-3.26.1-3274-SUSE-oS13.1-x86_64]

        Sharename       Type      Comment
        ---------       ----      -------
        profiles        Disk      Network Profiles Service
        users           Disk      All users
        groups          Disk      All groups
        print$          Disk      Printer Drivers
        FG-Windows-D    Disk      windows auf ap-suse
        IPC$            IPC       IPC Service (Samba 4.1.11-3.26.1-3274-SUSE-oS13.1-x86_64)
        iP3600-series   Printer   Canon iP3600 series
        brotherdrucker  Printer   Brother MFC-J4410DW CUPS
        userxxxx        Disk      Home Directories
Domain=[WORKGROUP] OS=[Unix] Server=[Samba 4.1.11-3.26.1-3274-SUSE-oS13.1-x86_64]

        Server               Comment
        ---------            -------
        AP-SUSE              Samba 4.1.11-3.26.1-3274-SUSE-oS13.1-x86_64
        FRITZ-NAS            FRITZ!Box

        Workgroup            Master
        ---------            -------
        WORKGROUP            FRITZ-NAS

Gruss H.
 
S

spoensche

Füge der Freigabe mal noch
Code: 
valid users= +dein_user
hinzu. Erhöhe auch mal das Loglevel. Dazu im Abschnitt [global] folgendes einfügen
Code: 
log level = 6
.

Den smbd durchstarten, die Freigabe mounten, auf dem Sever mittels tail -f das Log im Auge haben und dann vom Client aus eine Datei auf der Freigabe anlegen.

Was sagt dann das Log?
 
susejunky

susejunky

Moderator
Teammitglied
Hallo zusammen,

auf meinem Notebook ist openSUSE 13.1 und Windows Vista im Dual-boot-Modus (auf MBR-Partitionen) installiert. Um Daten sowohl unter openSUSE als auch unter Windows nutzen zu können, habe ich eine NTFS-formatierte Partition eingerichtet, die ich (auf dem Notebook) wie folgt unter openSUSE (in /etc/fstab) einbinde:
Code: 
UUID=XXXXXXXXXXXX  /mnt/wshare  ntfs-3g  defaults,locale=de_DE.UTF-8  0 0
Damit ich auch von meinem PC aus (openSUSE 13.1 only) auf die Notebook-Daten zugreifen kann, stelle ich die NTFS-Partition mit dieser smb.conf
Code: 
[global]
	workgroup = WORKGROUP
	server string = Server %i %h %L mit SAMBA %v
	passdb backend = smbpasswd:/etc/samba/smbpasswd
	log file = /var/log/samba/log.%m
	max log size = 1000
	name resolve order = lmhosts, host, wins, bcast
	domain master = No
	dns proxy = No
	idmap config * : backend = tdb
	invalid users = root
	follow symlinks = No

[NTFSSHARE]
	comment = Datenaustausch mit Windows
	path = /mnt/wshare/
	read only = No
	create mask = 0666
	directory mask = 0777
	inherit acls = Yes
	store dos attributes = Yes
als SAMBA-share in meinem Netzwerk zur Verfügung.

Das share binde ich auf meinem PC (unter openSUSE) wie folgt ein (/etc/fstab):
Code: 
mount -t cifs -o rw,uid=USERNAME,gid=users,user=SAMBA-USERNAME,password=XXXXXXXX  //IP-ADRESSE/NTFSSHARE /mnt/wshare
(Tatsächlich benutze ich - aus Sicherheitsgründen - die Option credentials= anstelle der Angaben user= und password=. Aber das dürfte für das hier geschilderte Problem nicht von Bedeutung sein.)

Damit funktioniert alles problemlos; d.h. sowohl von meinem PC aus, als auch auf dem Notebook selbst (unter openSUSE und Windows) kann ich auf der NTFS-Partition lesen, schreiben, erstellen und löschen. Da auf meinem PC kein Windows installiert ist, kann ich leider nicht sagen, ob das SAMBA-share des Notebooks auch von einem Windows-Client genutzt werden könnte.

Folgendes könnte auch noch von Bedeutung:


  1. [1]
    Die Einbindung des NTFS-Laufwerks mit der Option "default" gibt allen openSUSE-Usern auf meinem Notebook vollen Zugriff auf das Laufwerk (keine benutzerspezifischen Einschränkungen).
    [2]
    Ich nutze nicht die Möglichkeit für erweiterte Zugriffsrechte mit ntfs-3g; d.h. auf dem NTFS-Laufwerk des Notebooks existiert keine .UserMapping-Datei.
    [3]
    SAMBA-USER ist sowohl auf meinem Notebook als auch auf meinem PC ein Benutzer ohne jegliche Rechte (und auch ohne Login-shell). Ich habe ihn nur angelegt, damit ich einen Samba-Benutzer mit einem Kennwort anlegen kann.

Was ich nicht wirklich verstehe ist, warum bei halo44 das Anlegen und Löschen von Dateien funktioniert (denn meines Erachtens ist, was Zugriffsrechte anbelangt, Anlegen = Löschen = Schreiben).

Aber vielleicht helfen die obigen Informationen trotzdem weiter.

Viele Grüße

susejunky
 
susejunky

susejunky

Moderator
Teammitglied
Hallo zusammen,

da ist mir ein kleiner Fehler unterlaufen:

susejunky schrieb:
Das share binde ich auf meinem PC (unter openSUSE) wie folgt ein (/etc/fstab):
Code: 
mount -t cifs -o rw,uid=USERNAME,gid=users,user=SAMBA-USERNAME,password=XXXXXXXX  //IP-ADRESSE/NTFSSHARE /mnt/wshare
Zum Vergrößern anklicken....
Der Eintrag in der /etc/fstab meines PCs sieht natürlich wie folgt aus:
Code: 
//IP-ADRESSE/NTFSSHARE /mnt/wshare cifs nofail,rw,uid=USERNAME,gid=users,user=SAMBA-USERNAME,password=XXXXXXXX  0 0

Und hier noch ein Hinweis für den Test von SAMBA-Konfigurationen:

Angeblich werden bei der Nutzung des SMB-Protokolls bestimmte Informationen auf allen Clients des Netzes zwischengespeichert. Das kann dazu führen, dass Änderungen an der Konfiguration eines Clients ggf. erst zeitverzögert im Netz wirksam werden. Ich konnte die eine oder andere grundlegenden Änderungen an der smb.conf eines Rechners nur dadurch wirksam machen, dass ich alle Rechner im Netz (inkl. NAS) neu gebootet habe. Aber da gibt es vielleicht auch elegantere Wege (die ich aber leider nicht kenne).

Viele Grüße

susejunky
 
J

josef-wien

susejunky schrieb:
Was ich nicht wirklich verstehe ist, warum bei halo44 das Anlegen und Löschen von Dateien funktioniert (denn meines Erachtens ist, was Zugriffsrechte anbelangt, Anlegen = Löschen = Schreiben).
Zum Vergrößern anklicken....
Um Dateien anlegen, umbenennen oder löschen zu können, brauchst Du eine Schreibberechtigung auf das Verzeichnis. Um Dateien mit Inhalt befüllen oder diesen Inhalt ändern zu können, brauchst Du eine Schreibberechtigung auf die Datei. Welche Umstände dazu führen, daß halo44 das eine hat und das andere nicht, kann ich mangels Samba nicht sagen.
 
OP
H

halo44

spoensche schrieb:
Füge der Freigabe mal noch
Code: 
valid users= +dein_user
hinzu. Erhöhe auch mal das Loglevel. Dazu im Abschnitt [global] folgendes einfügen
Code: 
log level = 6
.

Den smbd durchstarten, die Freigabe mounten, auf dem Sever mittels tail -f das Log im Auge haben und dann vom Client aus eine Datei auf der Freigabe anlegen.

Was sagt dann das Log?
Zum Vergrößern anklicken....

Log Level habe ich auf 6 gestellt und meinen Benutzernamen bei valid users angegeben.

Beim Versuch das Log zum Zeitpunkt des Schreibversuchs im Auge zu behalten wurde ich mit Informationen zugeschüttet (um die 6000 Zeilen).

Ich habe daher die log.smbd eingelesen und den Zeitpunkt des Schreibversuchs selektiert, was immer noch 326 Zeilen ergab.

Hier habe ich mal alle Zeilen, die "fail", "error", "cryptsetup.sh" (die von mir gewählte Datei) oder den Benutzernamen enthalten zusammengestellt :

Code: 
[2014/09/30 09:23:18.016644,  5] ../source3/smbd/filename.c:258(unix_convert)
  unix_convert called on file "MediathekView/mp4/cryptsetup.sh"
[2014/09/30 09:23:18.016851,  5] ../source3/smbd/filename.c:421(unix_convert)
  unix_convert begin: name = MediathekView/mp4/cryptsetup.sh, dirpath = MediathekView/mp4, start = cryptsetup.sh
[2014/09/30 09:23:18.017165,  5] ../source3/smbd/filename.c:185(check_parent_exists)
  check_parent_exists: name = MediathekView/mp4/cryptsetup.sh, dirpath = MediathekView/mp4, start = cryptsetup.sh
[2014/09/30 09:23:18.017561,  5] ../source3/smbd/filename.c:816(unix_convert)
  New file cryptsetup.sh
[2014/09/30 09:23:18.017654,  3] ../source3/smbd/vfs.c:1137(check_reduced_name)
  check_reduced_name [MediathekView/mp4/cryptsetup.sh] [/windows]
[2014/09/30 09:23:18.018084,  3] ../source3/smbd/vfs.c:1267(check_reduced_name)
  check_reduced_name: MediathekView/mp4/cryptsetup.sh reduced to /windows/MediathekView/mp4/cryptsetup.sh
[2014/09/30 09:23:18.018308,  3] ../source3/smbd/trans2.c:5443(call_trans2qfilepathinfo)
  call_trans2qfilepathinfo: SMB_VFS_LSTAT of MediathekView/mp4/cryptsetup.sh failed (No such file or directory)
[2014/09/30 09:23:18.018411,  3] ../source3/smbd/error.c:82(error_packet_set)
  NT error packet at ../source3/smbd/trans2.c(5445) cmd=50 (SMBtrans2) NT_STATUS_OBJECT_NAME_NOT_FOUND
[2014/09/30 09:23:18.020560,  5] ../source3/smbd/filename.c:258(unix_convert)
  unix_convert called on file "MediathekView/mp4/cryptsetup.sh"
[2014/09/30 09:23:18.020763,  5] ../source3/smbd/filename.c:421(unix_convert)
  unix_convert begin: name = MediathekView/mp4/cryptsetup.sh, dirpath = MediathekView/mp4, start = cryptsetup.sh
[2014/09/30 09:23:18.021066,  5] ../source3/smbd/filename.c:185(check_parent_exists)
  check_parent_exists: name = MediathekView/mp4/cryptsetup.sh, dirpath = MediathekView/mp4, start = cryptsetup.sh
[2014/09/30 09:23:18.021461,  5] ../source3/smbd/filename.c:816(unix_convert)
  New file cryptsetup.sh
[2014/09/30 09:23:18.021556,  3] ../source3/smbd/vfs.c:1137(check_reduced_name)
  check_reduced_name [MediathekView/mp4/cryptsetup.sh] [/windows]
[2014/09/30 09:23:18.021989,  3] ../source3/smbd/vfs.c:1267(check_reduced_name)
  check_reduced_name: MediathekView/mp4/cryptsetup.sh reduced to /windows/MediathekView/mp4/cryptsetup.sh
[2014/09/30 09:23:18.022183,  3] ../source3/smbd/trans2.c:8267(call_trans2setfilepathinfo)
  call_trans2setfilepathinfo(6) MediathekView/mp4/cryptsetup.sh (fnum [fsp is NULL]) info_level=521 totdata=18
[2014/09/30 09:23:18.022289,  3] ../source3/smbd/trans2.c:7844(smbd_do_setfilepathinfo)
  smbd_do_setfilepathinfo: MediathekView/mp4/cryptsetup.sh (fnum [fsp is NULL]) info_level=521 totdata=18
[2014/09/30 09:23:18.023412,  5] ../source3/passdb/lookup_sid.c:1163(uid_to_sid)
  uid_to_sid: winbind failed to find a sid for uid 0
[2014/09/30 09:23:18.024237,  5] ../source3/passdb/pdb_tdb.c:594(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_root
[2014/09/30 09:23:18.024555,  5] ../source3/passdb/lookup_sid.c:1212(gid_to_sid)
  gid_to_sid: winbind failed to find a sid for gid 100
[2014/09/30 09:23:18.025500,  5] ../source3/passdb/lookup_sid.c:1163(uid_to_sid)
  uid_to_sid: winbind failed to find a sid for uid 0
[2014/09/30 09:23:18.026288,  5] ../source3/passdb/pdb_tdb.c:594(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_root
[2014/09/30 09:23:18.026595,  5] ../source3/passdb/lookup_sid.c:1212(gid_to_sid)
  gid_to_sid: winbind failed to find a sid for gid 100
[2014/09/30 09:23:18.067987,  2] ../source3/smbd/open.c:976(open_file)
  userxxxx opened file MediathekView/mp4/cryptsetup.sh read=No write=Yes (numopen=1)
[2014/09/30 09:23:18.068437,  5] ../source3/smbd/oplock.c:89(set_file_oplock)
  set_file_oplock: granted oplock on file MediathekView/mp4/cryptsetup.sh, 815:40:0/1638030241, tv_sec = 542a5a66, tv_usec = 5777
[2014/09/30 09:23:18.071522,  5] ../source3/passdb/lookup_sid.c:1163(uid_to_sid)
  uid_to_sid: winbind failed to find a sid for uid 0
[2014/09/30 09:23:18.072435,  5] ../source3/passdb/pdb_tdb.c:594(tdbsam_getsampwnam)
  pdb_getsampwnam (TDB): error fetching database.
   Key: USER_root
[2014/09/30 09:23:18.072840,  5] ../source3/passdb/lookup_sid.c:1212(gid_to_sid)
  gid_to_sid: winbind failed to find a sid for gid 100
[2014/09/30 09:23:18.077342,  2] ../source3/smbd/close.c:780(close_normal_file)
  userxxxx closed file MediathekView/mp4/cryptsetup.sh (numopen=0) NT_STATUS_OK

Vielleicht kannst Du damit mehr anfangen als ich.

Gruss H.
 
OP
H

halo44

@ susejunky

Danke auch Dir für Dein Engagement.

Dein Eintrag in der /etc/fstab des Servers
Code: 
UUID=XXXXXXXXXXXX  /mnt/wshare  ntfs-3g  defaults,locale=de_DE.UTF-8  0 0
Bei mir sieht der derzeit so aus
Code: 
UUID=XXXXXXXXXXXX  /windows  ntfs-3g  users,gid=users,fmask=133,gmask=022,locale=de_DE.UTF-8  0 0

Da ich lange keine Windows-Installation mehr auf meinen Rechnern hatte, habe ich mir diesen Eintrag aus alten Unterlagen rausgekramt. Damals hatte ich auf meinen Rechnern noch Dual-Boot-Systeme und konnte mit diesen fstab-Optionen auch auf Windows-Partitionen zugreifen. Allerdings habe ich damals nicht von Suse-Clients auf NTFS-Partitionen, die auf einem Suse-Server gemountet waren, per Samba zugegriffen.

Weil die damalige Anwendung aber funktionierte, kam ich jetzt nicht auf die Idee einen anderen fstab-Eintrag zu verwenden.

Ich habe jetzt mal Deine Einstellung gewählt und kann nun auch neue Dateien schreiben. Vermutlich waren die gmask- und fmask-Optionen für meine neue Anwendung nicht die richtigen. spoensche hatte ja schon in einem seiner Beiträge die Einstellung dieser Optionen beim Mount-Befehl angeregt. Dies habe ich dann auch beim Mounten auf dem Client angewendet. Anscheinend war aber hier die /etc/fstab des Servers vorrangig.

Danke Euch allen für die Hilfe. Sollten keine Einwände mehr kommen, werde ich in Kürze das Thema als "gelöst" markieren.

Gruss H.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben