[opensuse] deleting files from cifs
Hi I have a NAS with hdmi used as a home video recorder. I have to communicate with it using cifs. Here is the smb.conf on the NAS: cat smb.conf [global] load printers = no disable spoolss = yes syslog = 1 security = share dns proxy = no debug level = 0 netbios name = NAS workgroup = MSHOME server string = Samba Server [rec] guest ok = yes comment = Rec Partition path = /usr/local/etc/hdd/dvdvr writable = no read only = yes [part1] guest ok = yes comment =HDD Partition 1 path = /usr/local/etc/hdd/volumes/HDD1 writable = yes read only = no [part2] guest ok = yes comment =HDD Partition 2 path = /usr/local/etc/hdd/volumes/HDD2 writable = yes read only = no If I mount it: mount -t cifs //192.168.1.4/part2 /mnt and delete a file from it, it leaves a file called e.g. cifs03d8 of the same size as the file I've just deleted. I then unmount the cifs on /mnt, Then I have to telnet to the NAS and delete the cifsxxxx file at the command line. Which is instantaneous. But a pain. If I use dolphin or konq to access the NAS: smb:/192.168.1.4/part2 select the file and then hit shift-Supr (I think it's shift-Del on a us keyboard), it deletes it cleanly but takes much longer. What is the difference between mounting the cifs share and using the smb:/ protocol in dolphin? NAS: busybox Client: 11.2 kde 4.3.4 updated yesterday. Both boxes rebooted Thanks, L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jan 15, 2010 at 05:37:14PM +0100, lynn wrote: [ 8< ]
[part2] guest ok = yes comment =HDD Partition 2 path = /usr/local/etc/hdd/volumes/HDD2 writable = yes read only = no
You might try to set the "unix extensions" parameter to yes. Hm, that's the default. Please check nevertheless with testparm -s --parameter-name "unix extensions" to ensure it's not disable on your system.
If I mount it:
mount -t cifs //192.168.1.4/part2 /mnt
and delete a file from it, it leaves a file called e.g. cifs03d8 of the same size as the file I've just deleted. I then unmount the cifs on /mnt, Then I have to telnet to the NAS and delete the cifsxxxx file at the command line. Which is instantaneous. But a pain.
If I use dolphin or konq to access the NAS:
smb:/192.168.1.4/part2
select the file and then hit shift-Supr (I think it's shift-Del on a us keyboard), it deletes it cleanly but takes much longer.
See http://en.openSUSE.org/Bugs/Samba section "Debugging cifs vfs client" and file a bug if you still see this issue.
What is the difference between mounting the cifs share and using the smb:/ protocol in dolphin?
The call to "mount -t cifs ..." uses the Linux kernel cifs client. While applications like dolphin or konq use libsmbclient. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
On Friday 15 January 2010 21:08:22 Lars Müller wrote:
On Fri, Jan 15, 2010 at 05:37:14PM +0100, lynn wrote: [ 8< ]
[part2] guest ok = yes comment =HDD Partition 2 path = /usr/local/etc/hdd/volumes/HDD2 writable = yes read only = no
You might try to set the "unix extensions" parameter to yes. Hm, that's the default.
Please check nevertheless with
testparm -s --parameter-name "unix extensions"
to ensure it's not disable on your system.
If I mount it:
mount -t cifs //192.168.1.4/part2 /mnt
and delete a file from it, it leaves a file called e.g. cifs03d8 of the same size as the file I've just deleted. I then unmount the cifs on /mnt, Then I have to telnet to the NAS and delete the cifsxxxx file at the command line. Which is instantaneous. But a pain.
If I use dolphin or konq to access the NAS:
smb:/192.168.1.4/part2
select the file and then hit shift-Supr (I think it's shift-Del on a us keyboard), it deletes it cleanly but takes much longer.
See http://en.openSUSE.org/Bugs/Samba section "Debugging cifs vfs client" and file a bug if you still see this issue.
What is the difference between mounting the cifs share and using the smb:/ protocol in dolphin?
The call to "mount -t cifs ..." uses the Linux kernel cifs client.
While applications like dolphin or konq use libsmbclient.
Lars
Hi Lars That was a very informative reply and thanks for that. The output of the command you suggested is: testparm -s --parameter-name "unix extensions" Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[profiles]" Processing section "[users]" Processing section "[groups]" Processing section "[printers]" Processing section "[print$]" Loaded services file OK. Yes The bug report looks like a daunting process eg: tcpdump -s0 -w cifs-debug.cap 'port 137 || 138 || 139 || 445' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes sits there until I type ctrl-c 0 packets captured 0 packets received by filter 0 packets dropped by kernel I can mount and unmount fine. Just wondering if this is OK or whether anyone else uses NAS devices as hdmi recorders. Thanks L x -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Fri, Jan 15, 2010 at 10:43:47PM +0100, lynn wrote: [8<]
That was a very informative reply and thanks for that. The output of the command you suggested is:
testparm -s --parameter-name "unix extensions" Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[profiles]" Processing section "[users]" Processing section "[groups]" Processing section "[printers]" Processing section "[print$]" Loaded services file OK. Yes
On the NAS box or on your SUSE system? The sections named groups and users look very like the default SUSE smb.conf. The intention was to let you call testparm on the NAS system. If you're able to get a shell there.
The bug report looks like a daunting process eg:
tcpdump -s0 -w cifs-debug.cap 'port 137 || 138 || 139 || 445' tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
sits there until I type ctrl-c
0 packets captured 0 packets received by filter 0 packets dropped by kernel
Looks like 0 communication and fits to the assumptions I made before. Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
participants (2)
-
Lars Müller -
lynn