can't save file in samba share

[Ghido]

Binary package hint: gvfs

I use ubuntu 08.10 intrepid ibex
When I try to save a file with gedit or openoffice.org in a samba sharing i get an I/O error but if i copied file with nautilus i don't get errors. i mount samba share with libpam-mount and my .pam_mount.conf.xml entry is:

<volume fstype="cifs" server="server" path="%(USER)"
        mountpoint="/media/%(USER)/folder"/>

with ubuntu hardy 08.04 I had no problems

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 8.10
ExecutablePath: /usr/bin/nautilus
Package: nautilus 1:2.24.1-0ubuntu1
ProcEnviron:
 LANGUAGE=it_IT.UTF-8
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
SourcePackage: nautilus
Uname: Linux 2.6.27-7-generic i686

[sipiatti (sipiatti)]

same here, I was unable to save any document with openoffice what was opened from an smb share mounted by gvfs

In Hardy it was fine.
I use the attached script to mount my smb shares with gvfs. I can access the files through nautilus or console, can copy, move, delete, etc.
Openoffice says I/O error while saving.

This behavior started right after upgrading to Intrepid. It is unacceptable. !!!

[Sebastien Bacher (seb128)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

 * Is this reproducible?
 * If so, what specific steps should we take to recreate this bug?
 * Does nautilus manages to copy files to this directory?

 This will help us to find and resolve the problem.

[Ghido (paolo-ghido)]

Sebastien Bacher ha scritto:
> Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:
>
> * Is this reproducible?
>
Yes i tried on more pc with ubuntu intrepid ibex and i have the same
problem on all pc
> * If so, what specific steps should we take to recreate this bug?
>
mount remote samba share trough libpam-mount and try to save from
openoffice.org or gedit
> * Does nautilus manages to copy files to this directory?
>
yes i can copy file directly from nautilus

Bye

Ghido

[sipiatti (sipiatti)]

 * Is this reproducible?
definetelly. It is the same always. Can open with ooo, but when saving, I got the same error every time.

 * If so, what specific steps should we take to recreate this bug?
mount an smb share. open a file with openoffice, edit something in it and try to save.

 * Does nautilus manages to copy files to this directory?
nautilus works fine, also I can copy move delete files via console.

[richbl (richbl)]

This is an easily reproducible bug that appears to exist in OpenOffice 3.0 as it relates to samba.

I'm running OpenOffice.org 3.0.0 (OOO300m9, Build: 9358) on Ubuntu Release 8.10, Kernel Linux 2.6.27-8-generic, GNOME 2.24.1, samba version 2:3.2.3-1ubuntu3.1.

I can further confirm that it can be reproduced over either a smb-connected device that is a native Windows (NTFS) share, and a native Debian (ext3) share.

Does:

0) From the Ubuntu menu, Places/Connect to Server, create an smb: share.
1) From Nautilus or the Ubuntu menu, mount the smb share.
2) From Nautilus or OpenOffice, navigate to and then open a document OR create a new document in OpenOffice.
3) Edit document in OpenOffice.
4) In OpenOffice, from the File menu, choose Save. If the document is new, give it a new name.
5) In the OpenOffice Save dialog, choose the Save button.

Two error messages are generated:

OpenOffice.org 3.0 - Error saving the document Untitled1: Nonexistent file.

Then:

OpenOffice.org 3.0 - Error saving the document Untitled1: General Error. General input/output error.

Should:

OpenOffice should save new and modified (existing) files to an smb: share.

I can successfully save this file locally and then copy it to the appropriate smb: share with no permission problems. Alternately, I can create, open and edit a file on either smb: share in gedit, then save that file with no problem as well.

If there's any additional information I can provide, please let me know.

rich

[Giuseppe Barichello (gbarichello)]

Same nasty problem here.
Tried to mount the share with many combinations of the permissions options (such as "noperm"): no luck.
Samba server log doesn't seem to show anything relevant either.

TIA,

Giuseppe

[Giuseppe Barichello (gbarichello)]

Not sure it is a gvfs problem: I'm running xubuntu and mounting samba shares through a command in /etc/network/interfaces using smbmount.
I get the same behaviour described above: can create, move, rename and delete files using thunar or shell or mc. But when I try to save a file from an application (OO, but also scite, mousepad...) I get either I/O error or write error.

I suggest to increase bug importance, since it is really annoying for all-day working on shared folders.

Giuseppe

[Jason (boards188)]

I had the same problem and found a workaround here: http://user.services.openoffice.org/en/forum/viewtopic.php?f=9&p=59754

Basically, I unmounted the share, I added the "nounix" option in my /etc/fstab statement for mounting the smb/cifs share (as shown below), then remounted.

//192.168.1.2/public /media/samba cifs nounix,users,guest,uid=youruser

This seems to work for me.

jp

[theultimate (theultimate2)]

I had the same problem with Ubuntu 8.10. Thanks Jason, nounix option solved the problem for me.

[Sebastien Bacher (seb128)]

could you try if that's still an issue in jaunty?

[Ghido (paolo-ghido)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, unfortunately i can try when jaunty is stable because i use ltsp
on my production server!

Sebastien Bacher ha scritto:
> could you try if that's still an issue in jaunty?
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkncXA4ACgkQ254zyA/2IqKJAACgiPWOCqhVleKIxCWX/wwYHPRw
vdAAmwXoMUTdpJ3DIfiO0SY2hFHOmIes
=Eumb
-----END PGP SIGNATURE-----

[Wolfgang (wt-lists)]

Sebastien,

I tried it today with jaunty in Openoffice and gedit and I can confirm that both worked!

What I did:
- unmounted samba share
- removed "nounix" option in /etc/fstab
- mounted samba share
- opened, edited and saved file in openoffice - worked
- opened, edited and saved file in gedit - worked

this is my fstab entry:
//smb-server-name/public /media/public cifs users,noauto,iocharset=utf8,credentials=/home/user/.smbcredentials,uid=1000,gid=1000 0 0

gvfs version: 1.2.0-0ubuntu2

br
Wolfgang

[Sebastien Bacher (seb128)]

closing since that works correctly now

[Andrew McRae (ajmcrae)]

Well as usual in the Linux world we see bug reports being closed when the problem has not been fixed.
If you try to use smbmount (ie mount.cifs) in Jaunty it still fails when trying to save files.

Notice the person who said it was "fixed" had to change their configuration to get it to work! That's a kludge to their system to work around a bug in Ubuntu. No-one should have to change any parameters to smbmount or fstab to get their SMB shares mounted when the same commands worked fine in Hardy. Clearly a bug has been written between Hardy and Intrepid and is still here in Jaunty.

My (former) Hardy and (present) Jaunty configuration uses this Sessions startup command:
  smbmount '\\192.168.1.2\public' /home/andrew/naspublic -o guest

This worked fine in Hardy Heron, but neither GEdit nor OpenOffice nor Audacious can save changes to files opened from the mountpoint. They should be treated identically to any other filesystem file, and I repeat it worked perfectly in Hardy.

There's three short-term workarounds, none of which are nice:
A) Uninstall Jaunty and go back to Hardy, or
B) Switch to using Windows XP, or
C) Copy to local drive, edit, copy back.

Option B actually is the easiest since I dual boot Windows anyway and could install Microsoft Windows version of OOo.

Would prefer it if Ubuntu programmers could just fix the bug they added.

[halfsoul (joelishness)]

A fix has NOT been released. Please, re-open this bug!

System: Ubuntu 9.04 (Jaunty), kernel 2.6.28-15-generic
Affected software: OpenOffice.org 3.0.1, gedit

To duplicate:
joel@ubuntu-desktop:~$ sudo gedit /etc/fstab
"# Network Drive via Samba
#//192.168.0.200/Volume_1 /media/DNS-323 cifs rw,nounix,auto,password= 0 0
//192.168.0.200/Volume_1 /media/DNS-323 cifs rw,auto,password= 0 0"

joel@ubuntu-desktop:~$ sudo umount /media/DNS-323
joel@ubuntu-desktop:~$ sudo mount -a

Open "bills_090813.ods"
Save As "bills_090823" (note that this is a different filename) = error:
"Error saving the document bills_090813:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."
OK (note that the filename in the error is the originally-opened name)

Save As "bills_090823" (trying again)
"Error saving the document bills_090813:
General Error.
General input/output error."
OK (note that the filename in the error is the originally-opened name)
File "bills_090823.ods" gets created, size 0 bytes

Save As "bills_090823"
"The file already exists. Overwrite?"
Yes

"Error saving the document bills_090813:
Object not accessible.
The object cannot be accessed
due to insufficient user rights."
OK (note that the filename in the error is the originally-opened name)

Workaround:
joel@ubuntu-desktop:~$ sudo gedit /etc/fstab
# Network Drive via Samba
//192.168.0.200/Volume_1 /media/DNS-323 cifs rw,nounix,auto,password= 0 0
#//192.168.0.200/Volume_1 /media/DNS-323 cifs rw,auto,password= 0 0

joel@ubuntu-desktop:~$ sudo umount /media/DNS-323
joel@ubuntu-desktop:~$ sudo mount -a

Delete "bills_090823.ods" (the 0 byte file from earlier failed attempt)
Open "bills_090813.ods"
Save As "bills_090823" = no errors, file "bills_090823.ods" gets created, size & contents correct

This workaround is inappropriate for use, because with the nounix mounting option, file modified date/time gets forgotten when copying/moving files. Please actually release a fix.

[Steve French (smfrench)]

If "nodfs" mount option works around the problem then this is a duplicate issue, as suggested, and long since addressed. Remember, there is a clear SERVER bug which has been fixed for quite a while, but only clients which support BOTH "unix extensions" and "dfs" would see it (which is why the two suggested workarounds - "nodfs" or "nounix" on mount could work around it).

Remember that the user who had permission issues could have a different problem (e.g. uids that don't match on clients and server - perhaps they should override the default uid and gid and/or turn off perm checking on the client ("noperm") mount option.