Samba - Dateien lassen sich nicht löschen

[letzter3]

Hallo zusammen,

ich stelle eine für alle les-/schreibbare Freigabe bereit.
Die smb.conf

Code: Alles auswählen

root@ptLWL01:/etc/samba# cat smb.conf
[global]
 workgroup = smb
 security = share
 share modes = yes
    
[homes]
 comment = Home Directories
 browsable = no
 read only = no
 create mode = 0750
          
[public]
 path = /home/public/ 
 public = yes
 writable = yes
 comment = smb share
 printable = no
 guest ok = yes
 create mode = 0777
 directory mask = 0777
root@ptLWL01:/etc/samba# 

Nun kann jeder Windows-user in die Freigabe schreiben.
Das Speichern aus Programmen in die Freigabe funktioniert manchmal nur 2. Versuch, ist aber hier nicht Thema, kann aber vielleicht mit meinem Problem zu tun haben?

Angelegte Dateien lassen sich vom Inhalt her ändern (ich kann also in eine Textdatei schreiben und diese dann abspeichern).
Was nicht geht, ist das Löschen und Umbenennen von Dateien.

Die angelegten Dateien haben dann die Rechte 100766, Eigentümer ist nobody, Gruppe ist nogroup.
Wo ist mein Fehler? Werden weitere Info's benötigt?

[letzter3]

Keiner eine Idee?

[NAB]

Was sagt denn "testparm"?

[letzter3]

Code: Alles auswählen

root@ptLWL01:~# testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
WARNING: The "share modes" option is deprecated
Processing section "[homes]"
Processing section "[public]"
WARNING: The security=share option is deprecated
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        workgroup = SMB
        security = SHARE
        idmap config * : backend = tdb

[homes]
        comment = Home Directories
        read only = No
        create mask = 0750
        browseable = No

[public]
        comment = smb share
        path = /home/public/
        read only = No
        create mask = 0777
        directory mask = 0777
        guest ok = Yes
root@ptLWL01:~# 

Sollte ich das rlimit erhöhen? Hat das was mit meinem Problem zu tun?
Der Zugriff findet übrigens über eine VPN-Verbindung statt.

[hikaru]

Mein Halbwissen sagt mir, dass Gäste per default* keine Dateien manipulieren (oder anlegen/löschen?) dürfen, egal was die Rechte sagen. Nur echte User dürfen das, vorausgesetzt sie bekommen per Samba die Rechte zugesprochen UND haben lokal auf dem Server Schreibrechte.
Demnach dürfte die Lösung sowas wie die Option force user = letzter3 sein.

*) k.A. ob sich das ändern lässt

[NAB]

Ich dachte, "security=share" würde seit Samba 4 nun endgültig ignoriert werden. Das bringt mich zu der Frage ... welches Betriebssystem verwendest du eigentlich?

Und bei "share modes = yes" weiß ich nicht mal genau, was es macht, aber "yes" ist eh der Default, also nimm die Zeile mal raus.

[letzter3]

Ich verwende:

Code: Alles auswählen

Linux ptLWL01 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u3 x86_64
...
root@ptLWL01:~# cat /etc/issue
Debian GNU/Linux 7 \n \l

root@ptLWL01:~# 

Nehme ich beide von dir genannten Optionen raus, verlangt samba ein user + Password (was ich aber nicht habe).

[letzter3]

Ergänzung:

Code: Alles auswählen

root@ptLWL01:~# smbd --version
Version 3.6.6
root@ptLWL01:~# 

[NAB]

Nein, nein, "share modes = yes" kann raus. "security=share" müsste bei Debian 7 noch funktionieren.

Das mit dem "nobody" ist vollig korrekt ... sämtliche Gäste sind auf deinem System als "nobody" unterwegs. Das ist ein existierender user:

Code: Alles auswählen

cat /etc/passwd | grep nobody
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin

Schau dir mal die Rechte deines freigegebenen Verzeichnisses an, wem das gehört und wer da Zugriff hat. Du könntest es einfach zum Besitz des Users "nobody" machen.

[letzter3]

Code: Alles auswählen

root@ptLWL01:/home# ls -l
insgesamt 12
drwxr-xr-x  9 root    root    4096 Apr 14 02:26 backup
drwxr-xr-x 15 letzter letzter 4096 Apr 14 21:09 letzter
drwxrwxrwx  4 root    root    4096 Dez 30 19:04 public
root@ptLWL01:/home# 

root@ptLWL01:~# cd /home
root@ptLWL01:/home# ls
backup  letzter  public
root@ptLWL01:/home# ls -l public
insgesamt 8
drwxrwxrwx  5 nobody nogroup 4096 Mär 10 20:19 LWL
drwxrwxrwx+ 5 nobody nogroup 4096 Apr  3 18:20 PCH
root@ptLWL01:/home# 

Muss /home/public nobody:nogroup haben?

[letzter3]

Seltsames System:
log des smbd:

Code: Alles auswählen

  smbd version 3.6.6 started.
  Copyright Andrew Tridgell and the Samba Team 1992-2011
[2016/04/14 21:03:57.251962,  0] printing/print_cups.c:110(cups_connect)
  Unable to connect to CUPS server localhost:631 - Verbindungsaufbau abgelehnt
[2016/04/14 21:03:57.254018,  0] printing/print_cups.c:487(cups_async_callback)
  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2016/04/14 21:04:57.302108,  0] printing/print_cups.c:110(cups_connect)
  Unable to connect to CUPS server localhost:631 - Verbindungsaufbau abgelehnt
[2016/04/14 21:04:57.305795,  0] printing/print_cups.c:487(cups_async_callback)
  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2016/04/14 21:17:57.958224,  0] printing/print_cups.c:110(cups_connect)
  Unable to connect to CUPS server localhost:631 - Verbindungsaufbau abgelehnt
[2016/04/14 21:17:57.958768,  0] printing/print_cups.c:487(cups_async_callback)
  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
[2016/04/14 21:30:58.683648,  0] printing/print_cups.c:110(cups_connect)
  Unable to connect to CUPS server localhost:631 - Verbindungsaufbau abgelehnt
[2016/04/14 21:30:58.684058,  0] printing/print_cups.c:487(cups_async_callback)
  failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
root@ptLWL01:/var/log/samba# 

Allerdings ist die oben gepostete samba.conf vollständig. Heisst: Ich habe dort keine Drucker eingerichtet....

[NAB]

Muss /home/public nobody:nogroup haben?

Nein, eigentlich nicht, da haben ja alle alle Rechte. Aber das "+" in der Zeile von PCH ist interessant. Treten die Probleme eventuell nur in PCH auf? Dann müsste man sich mal die ACLs da anschauen.

Sonst sehe ich da keine Einschränkungen für "nobody" ... hab also auch keine Erklärung für das seltsame Verhalten.

Hier berichtet einer, dass er unter Windows Dateien löschen kann, unter Ubuntu allerdings nicht:
http://ubuntuforums.org/showthread.php?t=2157560
Es könnte also auch am Client liegen.

Und hier gibt es einen sehr langen Bug-Report:
https://bugzilla.samba.org/show_bug.cgi?id=8414
der sich auch über deine Samba-Version erstreckt, mit sehr unklaren Beschreibungen, wann es geht und wann nicht.

Einige da berichten, dass ein

Code: Alles auswählen

acl check permissions = No

unter [global] geholfen hat - das solltest du mal ausprobieren.

[letzter3]

Aber das "+" in der Zeile von PCH ist interessant. Treten die Probleme eventuell nur in PCH auf?

Kann ich gerade nicht testen, hole ich nach.

Dann müsste man sich mal die ACLs da anschauen.

Hab ja gar keine gesetzt??

... hab also auch keine Erklärung für das seltsame Verhalten.

Sehr schade, trotzdem danke bis hierher.

Hier berichtet einer, dass er unter Windows Dateien löschen kann, unter Ubuntu allerdings nicht:
http://ubuntuforums.org/showthread.php?t=2157560
Es könnte also auch am Client liegen.

Und hier gibt es einen sehr langen Bug-Report:
https://bugzilla.samba.org/show_bug.cgi?id=8414
der sich auch über deine Samba-Version erstreckt, mit sehr unklaren Beschreibungen, wann es geht und wann nicht.

Einige da berichten, dass ein

Code: Alles auswählen

acl check permissions = No

unter [global] geholfen hat - das solltest du mal ausprobieren.

Ich werde lesen, testen und berichten.

[letzter3]

Das scheint geholfen zu haben.

Dennoch bleibt mir die security-Option schleierhaft

Code: Alles auswählen

root@ptLWL01:/etc/samba# testparm             
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[homes]"
Processing section "[public]"
WARNING: The security=share option is deprecated
Loaded services file OK.
Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions

[global]
        workgroup = SMB
        security = SHARE
        client signing = required
        socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
        idmap config * : backend = tdb
        acl check permissions = No

[homes]
        comment = Home Directories
        read only = No
        create mask = 0750
        browseable = No

[public]
        comment = smb share
        path = /home/public/
        read only = No
        create mask = 0777
        directory mask = 0777
        guest ok = Yes

Code: Alles auswählen

root@ptLWL01:/etc/samba# cat smb.conf
[global]
 workgroup = smb
security = share
# share modes = yes
acl check permissions = no
socket options = TCP_NODELAY SO_RCVBUF=16384 SO_SNDBUF=16384
    
[homes]
 comment = Home Directories
 browsable = no
 read only = no
 create mode = 0750
          
[public]
 path = /home/public/ 
 public = yes
 browsable = yes
 writable = yes
 comment = smb share
 printable = no
 guest ok = yes
 create mode = 0777
 directory mask = 0777
                 
root@ptLWL01:/etc/samba# 

Ebenfalls unklar, warum versucht wird, cups anzusprechen. Siehe log weiter oben.

[NAB]

Mir ist eher unklar, warum "acl check permissions = No" hilft. Ist das nun ein Bug oder war es vorher ein Konfigurationsfehler?

"security = share" wird mit Samba 4 (ab Jessie) abgeschafft. Du kannst immer noch das gleiche erreichen, musst dann aber explizit angeben, dass unbekannte User auf "nobody" gemappt werden sollen. Dazu gibt's zig Anleitungen im Netz.

Samba fragt ja nur an, ob Cups läuft, und kriegt ne negative Antwort. Ein Problem sehe ich da nicht. Vielleicht gibt's irgendeine Option, die diese Anfragen ausschaltet.