[SRU] smb: Error while copying file, "Invalid argument"

To be clear, the remote PC is running Win XP 32-bit with Service Pack 3 (all patches up-to-date). It is connected to the ubuntu PC via a local shared router (local LAN, ip address = 192.168.1.3, 192.168.1.2), no other PCs are on this network.

Thank you for your bug report. The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

Same issue happening here on Karmic!

I get this also on Karmic now, but it wasn't before and I have a good indication that in my case its probably related to a server change (Windows 2000 server).

This bug should be reported upstream, but I do not have a Gnome account. I have read the instructions to report the bug, but I am not clear on what to do (I do not understand the process).

Can someone please submit this bug upstream? Thank you.

Opened GNOME bug #588391 : http://bugzilla.gnome.org/show_bug.cgi?id=588391

I'm not sure how one links bugs in external trackers to launchpad.

I think the upstream link is working. The URL in the comment of 2009-06-29, leads to this page "Watching Another Project" https://wiki.ubuntu.com/Bugs/Watches. I attempted the instructions to add the link, but it appears that this was already done.

The "Remote bug watches" on the right side of this page, as well as the gvfs project status at the top of this page both point to Gnome bug #588391. The automated Bug Watch Updater indicates activity as well.

Opened by Oded Arbel. Thank you very much!

I suspect this bug is in libsmbclient and not in GNOME - I just reverted libsmbclient from 3.4 that comes with Karmic to libsmbclient 3.3.4 , and not everything works.

right that's what the upstream bug suggests too

Hi,
maybe #220434 is a duplicate of this bug?

Nope, 220434 is about the message being uninformative. This bug is about what's causing that message.

Sorry, I've completely misunderstood that bug report.... :P

I'm not sure what's going on with the upstream bug? http://bugzilla.gnome.org/show_bug.cgi?id=588391 shows (still) as "unconfirmed". Does anyone with know-how on the Gnome bug tracker know what's needed to bring this to the attention of the gnome devs?

It seems that Tomas Bzatek, the gvfs dev, asked for confirmation if this was reproducible on smbclient. I think the problem is that the confirmation came from the original bug-poster, possibly rendering the confirmation invalid?

I'm the reported of the GNOME bugzilla bug, and the confirmation came from another person. This should be confirmed in the GNOME bugzilla, but while some GNOME developers are very responsive to bugzilla reports, others are not as available. I'll ping Tomas in the bugzilla about this.

I try to avoid adding me-too's, but it is disconcerting to see the lack of activity / discussion on the upstream report. This is a showstopper bug for me, and I'm am quite concerned seeing the 2.27 beta gnome stuff coming shortly. I will gladly provide any debugging information needed to get this confirmed and on the dev's radar.

You are more then welcome to nudge the developers using GNOME's Bugzilla :-) , Just make sure that you are polite about it.

This issue was fixed upstream and appears to be fixed with the latest smbclient 3.4.0-3ubuntu1 on karmic.

tested and confirmed. fixed in karmic.

No change here, using AutoFS to mount my shares - they're all still read-only unless I run nautilus with sudo.

scaine@Groovy:~$ dpkg-query -W smbclient
smbclient 2:3.4.0-3ubuntu1

Latest smbclient appears to be installed and my auto.master simply mounts the share using smbclient. Is there something I'm missing here - perhaps something that needs to be updated in the auto.smb script in order to restore Jaunty's read/write behaviour using this new smbclient package?

I'll add the autofs package to this bug report in the hope that someone can help.

Przemysław Kochański, you've indicated that you've tested this and it works. Can you post details of what you tested? As previously stated, I've updated to smbclient 3.4.0-3 (now ubuntu5 as of posting), but all my smb shares are /still/ mounted read-only by autofs. Should I open another bug?

Steps to replicate :
1. Create a standard samba share on your server with read/write guest access, no password. I use Jaunty 64-bit for my server.
2. Install beta karmic on your client PC, then update fully.
3. Install autofs (I've also tried autofs5, with same result).
4. edit /etc/auto.master and uncomment /smb line
5. sudo invoke.rc.d autofs restart
6. Use nautilus to browse to /smb/<servername>/<sharename>

You'll notice your share is read-only. Now run gksudo nautilus and browse to the same directory for read/write access.

The exact same procedure on a Jaunty build results in read/write shares as expected.

I have another problem. Trough AutoFS I'm mounting some directories from my NAS.

$cat auto.master
/home/coudy/nas/ /etc/autofs/auto.coudy --ghost --timeout 5

$cat autofs.coudy
Videa;; -fstype=smbfs,username=coudy,password=***,iocharset=utf8,codepage=iso8859-1 ://nas.local/video
Verejne -fstype=smbfs,username=coudy,password=***,iocharset=utf8,codepage=iso8859-1 ://nas.local/public
Hudba -fstype=smbfs,username=coudy,password=***,iocharset=utf8,codepage=iso8859-1 ://nas.local/music
Fotky -fstype=smbfs,username=coudy,password=***,iocharset=utf8,codepage=iso8859-1 ://nas.local/photo
Neverejne -fstype=smbfs,username=coudy,password=***,iocharset=utf8,codepage=iso8859-1 ://nas.local/private

but when I visit /home/coudy/nas I can see only one share, and it is randomly assigned share.

In jaunty it was 100% working.

And is your share read-only? That's the issue I'm experiencing with autofs. I'd appreciate it if you could confirm this bug if so.

However, I don't think anyone is now tracking this bug. I added the "affects project" for autofs too late after the relevant gvfs issues were fixed. Combined with this bug report :
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/211631
which outlines how Karmic is unable to shutdown/restart gracefully when samba shares are specified in /etc/fstab, we now have the depressing situation whereby Karmic is unable to automatically create shares to samba.

And this bug :
https://bugs.edge.launchpad.net/gnome-mount/+bug/388444
which highlights that gvfs shares aren't automatically mounted appears to be dead too. I don't consider gvfs in its current state as much use for a networked PC. My only option at the moment is to consider abandoning samba and implementing NFS instead, although that's not an option I can take at my workplace.

I only have Karmic on one of my boxes. If I ever decide to install it beyond that, I'll probably raise additional bugs on this issue. For the moment, I've lost motivation.

I can confirm an ro problem with autofs accessing cifs shares in 9.10. My workaround is to access the share via places->network to get rw access. This problem exists on both the i386 and amd64 versions on 2 machines. autofs and smbfs packages installed, auto.smb enabled, credentials file created, - worked in 9.04 but not 9.10.

Putting noperm, nounix, rw options in auto.smb seem to make no difference. read only via autofs accessing the file shares on a NAS.

Hello, I can confirm this bug too.
I can write only as super user.

Thanks Bryan and Radoslav. I have marked this bug "confirmed" for autofs. If anyone else wishes to confirm, please use the "affects me too" link at the top of the page.

Can anyone advise whether autofs will get any attention on Launchpad or whether it's an upstream project? I'll go and research such now, but I'm still very new to bug tracking and the relationships between debian/gnome/ubuntu and so on.

The workaround in autofs is to add -gid=1000,uid=1000 (e.g.) to the map in auto.master so the directories created by autofs become owned by user 1000. That allows that user rw access. The problem is that autofs sets the directories rwx for owner and just r for group and other. I think autofs should set its directory permissions rwx all (777) and let the network share determine access.

Actually, that does work - thanks. Sadly, unlike Jaunty, autofs seems to "hang-on" to the share it creates, which in turn causes the dreaded "no response from server" message (and its associated 80 second hang) when shutting down or restarting. You'll only see this if you use wireless.

No sign of a fix for that any time soon, although I've just subscribed to the network manager mailing lists where I might ask why network manager shuts down its wireless connections instantly on shutdown/restart, but keeps ethernet connections open for so long.

i wouldn't mind if network manager honoured the /etc/init.d scripts order, but network manager drops the connection whole seconds before even the first such script is run. Hopefully one of the devs can point me in the right direction.

Not sure if this bug (in autofs) can be considered closed or not based on this find.

re the "no response from server" - there is a fix. I don't have the citation handy but the idea was to dismount network mounts earlier in the shutdown process. It was a script to add to the shutdown pile that killed any processes holding on to a share and then dismounted the share. I think it was discussed in Ubuntu Forums but its been a while so I'm not sure.

The shutdown bug is being discussed here : https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/211631?comments=all, but there's no fix as yet. The umountcifs.sh script does still work, but as I say, Network Manager drops the WIFI connection far, far too early in the shutdown process for it to have any impact. Seems to be a change from Jaunty to Karmic in how the shutdown scripts are processed - possibly upstart related, since even running umountcifs in K01 is quick enough.

Today I've downloaded new update trough synaptic for smbfs and smbclient. I can confirm that this bug no more exist on my computer. I can write to samba share, and autofs is now working like before.

I can confirm that this is still a problem on karmic. I just did a fresh install in a VM last night, and the only way I can get proper user/group perms is to use an old smb script that manually mounts the points with smbmount, passing the standard options:

-o password=$PASS,username=oubiwann,uid=1000,gid=1000

I have tried defining uid/gid in the auto.smb file to no effect; autofs continues to mount as root.

Here are my current versions:

Ubuntu 9.10
smbclient/smbfs 2:3.4.0-3ubuntu5.3
autofs 4.1.4+debian-2.1ubuntu2

/me uninstalls autofs and goes back to using manual scripts.

Still problem in Ubuntu 9.10, when I'm tryring to mount manually using command line, I can write to the shared folder, but when using nautilus, still cannot write to the shared folder.

I'm using:

Ubuntu 9.10
smbclient/smbfs 2:3.4.0-3ubuntu5.3
autofs 4.1.4+debian-2.1ubuntu2

and my server is:
Ubuntu 9.10
samba 2:3.4.0-3ubuntu5.3

Confirmed in Ubuntu Lucid, beta 2. Autofs still created the /smb folder with 755 permissions, as root. This means that regardless of your credentials, you can't write the resulting folder/share.

Putting :
/smb /etc/auto.smb uid=1000,gid=1000,--timeout=300

as your /etc/auto.master still works (see comment #27). Pretty much broken, still.

Please help,

I have a NAS server (NASLite - SMB). I can use Nautilus 2.22.5.1 in Ubuntu 8.04 to copy files from my hard drive to the NASLite server. When I try to do this with the newer Ubuntu 10.04, I get an error message from Nautilus "Invalid Argument". Funny thing, I can delete files, and move files around within the NAS server.

I would really like to use the newer Ubuntu 10.04, but it does not work for me. Please tell me how I can make it work.

With Ubuntu 10.04 I get an invalid argument when attempting to use Nautilus to transfer files to my NAS server via SMB.
Hint: Using Nautilus to transfer via SMB to a NAS server works for me under Ubuntu 8.04.3, but Nautilus with 10.04 does not work for me. This problem is fixed by using GNOME Commander to transfer files.
Could problem really be Nautilus?

Edward LeBlanc

> Date: Thu, 16 Sep 2010 11:19:22 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 393012] Re: smb: Error while copying file, "Invalid argument"
>
> ** Changed in: gvfs
> Status: Fix Released => Unknown
>
> ** Changed in: gvfs
> Importance: Unknown => High
>
> --
> smb: Error while copying file, "Invalid argument"
> https://bugs.launchpad.net/bugs/393012
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in autofs - automatic filesystem mounter: Confirmed
> Status in GVFS: Unknown
> Status in “gvfs” package in Ubuntu: Fix Released
> Status in “gvfs” package in Debian: Fix Released
>
> Bug description:
> Binary package hint: nautilus
>
> While copying a folder from ubuntu to a Windows XP PC, I get an error message, "Error while copying "Tarantula-1.jpg".
>
> "There was an error copying the file into smb://asus1/documents/Tarantula." Show more details: Invalid argument
>
> The source folder is called "Tarantula", which contains:
> /host/Documents and Settings/All Users/Documents/Tarantula> ls -sail
> total 15545
> 112420 0 drwxrwxrwx 1 root root 0 2009-06-27 11:41 .
> 3856 4 drwxrwxrwx 1 root root 4096 2009-06-27 16:43 ..
> 112426 1 -rwxrwxrwx 1 root root 59 2009-06-27 11:40 .picasa.ini
> -rwxrwxrwx 1 root root 2622811 2009-06-27 11:41 Tarantula-1.jpg
> -rwxrwxrwx 1 root root 2565675 2009-06-27 11:41 Tarantula-2.jpg
> -rwxrwxrwx 1 root root 2449986 2009-06-27 11:41 Tarantula-3.jpg
> -rwxrwxrwx 1 root root 2442001 2009-06-27 11:41 Tarantula-4.jpg
> -rwxrwxrwx 1 root root 2596930 2009-06-27 11:41 Tarantula-5.jpg
> -rwxrwxrwx 1 root root 3218977 2009-06-27 11:40 Tarantula.jpg
>
> I am able to read and delete files on the remote Win XP PC shared folder asus1/documents. The folder does not exist on this remote PC.
>
> At the start of the copy, Nautilus creates the folder "Tarantula", then terminates with the error: "Error while copying "Tarantula-1.jpg".
>
> The Tarantula folder on the remote PC (as reported from Nautilus 2.26.2 File Browser):
> Location: smb://asus1/documents/Tarantula
> Tarantula-1.jpg , size = 64.0 KB, type = JPEG Image, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
> .picasa.ini = 59 bytes, type = unknown, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
>
> It appears that the .ini file was copied completely, as I can open and read the file in a text editor. The JPEG image was partially copied when smb terminated. The problem can be repeated.
>
> This may be a problem with smb.
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 9.04
> ExecutablePath: /usr/bin/nautilus
> NonfreeKernelModules: nvidia
> Package: nautilus 1:2.26.2-0ubuntu2
> P...

This bug has apparently reared its ugly head again in Maverick, as was discussed in bug #659854 . I've marked it as a duplicate of this bug which I'm reopening.

To sum up the discussion on bug #659854 - the behavior is almost the same as the reports on this bug except that fact that the size of the file chunk that manages to be copied is changing from each invocation in a seemingly random fashion. This affects all file browsers (including Nautilus and Dolphin) but for some reason not the gvfs-fuse mount. It can however be easily reproduced using the gvfs-copy command line tool.

As noted in Bug #659854, this time in maverick, the problem appears only when copying files greater than 48kb. This symptom was never mentioned in Bug #393012. Could this be a different bug altogether?

I have the same problem, but with perhaps a bit more information.

I am able to copy files using nautilus to a samba share hosted on XPsp3 or earlier. The bug is only present (for me) when copying to a share hosted on Windows 7 or Server 2008r2. Something to do with the new authentication requirements?
I am able to copy files to the share using smbclient, or even the cp command to ~/.gvfs/sharename.
The bug only exists when using the Nautilus interface. The mount point created by Nautilus/gvfs also works fine.

* When copying to a Win7/Server2008r2 share via Nautilus:
  -files <48KB transfer correctly.
  -files >48KB transfer only the first 48KB.
* Copying via 'cp' to ~/.gvfs/sharename completes successfully.
* Copying via 'smbclient' completes successfully. ie: smbclient \\\\server\\share > cp foo.txt foo.txt
* Copying via 'mc' completes successfully.

Steps to reproduce:
1. Create a share on a Win7 or Server 2008r2 server.
2. Use Nautilus to browse to the share.
3. Copy file >48KB.
Result "Invalid Argument"

OR:
1. Create a share on a Win7 or Server 2008r2 server.
2. gvfs-copy foo.txt smb://server/share/
Result "Invalid Argument"

In my case, I can not reproduce against WinXP or earlier.
This is clearly a problem with gvfs-copy.

Should also mention that I have no problem reading data from the share.

Filed with bugzilla.gnome.org https://bugzilla.gnome.org/show_bug.cgi?id=633937

Ben: can you reproduce the problem using the gvfs-copy command line tool? can you reproduce the problem using KDE's Dolphin?

This is definitely a problem with smbclient. I just downgrade to samba 3.4.7 (from Lucid) and now have no problems copying files to smb shares.

The Maverick bug has been fixed in the samba code. Turns out the problem was with libsmbclient.

See https://bugzilla.gnome.org/show_bug.cgi?id=633937

for more information.

where can I get fixed packages for ubuntu 10.10? Any ppa repo maybe? I really don't wanna compile samba myself :(

Is that bug found in samba4 ?

And anybody built the patched version yet ?

Ubuntu 10.10 is crippled by this bug that prevents network copy. Everybody who is just trying to use Ubuntu Linux that is not a developer has no clue what to do. As of Nov 21 2010, with all updates applied I cannot copy anything via the network to my Windows 2003 server without getting the "Invalid argument"

I agree Amoor; this bug is critical but it is the release of Maverick with bugs like #160311 that really makes me nervous about the future fit and finish of the Ubuntu packaged GNOME desktop (to say nothing of the ghastly state of Unity in 10.10). I accept that re-installing Lucid would resolve most of the issues encountered with 10.10 but I'm baffled as to why Canonical aren't making a public effort to repair the credibility damage the presence of this bug and others in a "release" version has done to them.

So how is the backport of this fix from samba.org into the Ubuntu libsmbclient coming along?

Already fixed in upstream, but no fix for Ubuntu!
https://bugzilla.samba.org/show_bug.cgi?id=7791

> but I'm baffled as to why Canonical aren't making a public effort to repair the credibility damage the presence of this bug and others in a "release" version has done to them.

Ubuntu is a community project, while Canonical invest ressources to work on it Ubuntu is not limited to Canonical. The bug there just didn't get tnough duplicates and affect users to be raised until now out of the number of bug reports sent to launchpad, the ubuntu team will work on backporting the fix this week though

Also had the same issue since I upgraded to 10.10. I have since made sure I am up to date with the 1.6.4-0ubuntu1.1 version of gvfs but I still had the issue.

Something I did notice was that it only affected my access to shares in Windows Servers in our Domain using specific Domain Logon Credentials for the shares. Public Shares in the same servers had no issue.

I finally found a work-around by installing libsmbclient 2:3.4.7~dfsg-1ubuntu3.2 as was used in Lucid and that fixed the issue for me though I am not very comfortable with that fix.

Adding a Samba(Ubuntu) task, marking Triaged/High.

Accepted samba into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Hi, I've just installed version 2:3.5.4~dfsg-1ubuntu8.1and it seem to be okay. I did a quick test with a 1.2Mb file from my machine to the network server, and it went back and forth fine. I did this both before and after a reboot, just to make sure the new library was being used.

I can confirm the fix. I've also just updated Samba to 2:3.5.4~dfsg-1ubuntu8.1 from maverick-proposed and it has resolved the issues for me. I am now able to copy large files to a Windows 2008 share without getting the "Invalid Argument" error and the files now copy fully instead of just 64KB.

fixed with latest samba from maverick-proposed. Thanks a lot!

Thanks for testing! Please upload the fix to natty as well, so that this can go to -updates.

When the fix should come to -updates ?

This bug was fixed in the package samba - 2:3.5.6~dfsg-1ubuntu2

---------------
samba (2:3.5.6~dfsg-1ubuntu2) natty; urgency=low

  * debian/patches/fix-lpbug-393012.patch: Fix for "invalid arguement"
    when copying file from windows using nautilus. (LP: #393012)
 -- Chuck Short <email address hidden> Fri, 26 Nov 2010 10:00:08 -0500

But not released for Maverick yet ?

This bug was fixed in the package samba - 2:3.5.4~dfsg-1ubuntu8.1

---------------
samba (2:3.5.4~dfsg-1ubuntu8.1) maverick-proposed; urgency=low

  * debian/patches/fix-lpbug-393012.patch: gvfsd-smb (Gnome vfs) fails to copy
    files from a SMB share using SMB signing. (LP: #393012). Fix for taken
    from upstream (https://bugzilla.samba.org/show_bug.cgi?id=7791)
 -- Chuck Short <email address hidden> Mon, 22 Nov 2010 12:43:19 -0500

Finally! Thanks all.

Huzzah, fix works for me. Many thanks.

Works for me as well. Thanks

Works for me now.

Thanks so much.

Will this be implemented in 11.04 ?
I still get invalid argument using 10.1 with updates!

> Date: Fri, 10 Dec 2010 04:53:11 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 393012] Re: [SRU] smb: Error while copying file, "Invalid argument"
>
> Works for me now.
>
> Thanks so much.
>
> --
> You received this bug notification because you are a direct subscriber
> of the bug.
> https://bugs.launchpad.net/bugs/393012
>
> Title:
> [SRU] smb: Error while copying file, "Invalid argument"
>
> Status in autofs - automatic filesystem mounter:
> Confirmed
> Status in GVFS:
> Unknown
> Status in Samba:
> Fix Released
> Status in “gvfs” package in Ubuntu:
> Fix Released
> Status in “samba” package in Ubuntu:
> Fix Released
> Status in “gvfs” source package in Maverick:
> Invalid
> Status in “samba” source package in Maverick:
> Fix Released
> Status in “gvfs” package in Debian:
> Fix Released
>
> Bug description:
> Binary package hint: nautilus
>
> While copying a folder from ubuntu to a Windows XP PC, I get an error message, "Error while copying "Tarantula-1.jpg".
>
> "There was an error copying the file into smb://asus1/documents/Tarantula." Show more details: Invalid argument
>
> The source folder is called "Tarantula", which contains:
> /host/Documents and Settings/All Users/Documents/Tarantula> ls -sail
> total 15545
> 112420 0 drwxrwxrwx 1 root root 0 2009-06-27 11:41 .
> 3856 4 drwxrwxrwx 1 root root 4096 2009-06-27 16:43 ..
> 112426 1 -rwxrwxrwx 1 root root 59 2009-06-27 11:40 .picasa.ini
> -rwxrwxrwx 1 root root 2622811 2009-06-27 11:41 Tarantula-1.jpg
> -rwxrwxrwx 1 root root 2565675 2009-06-27 11:41 Tarantula-2.jpg
> -rwxrwxrwx 1 root root 2449986 2009-06-27 11:41 Tarantula-3.jpg
> -rwxrwxrwx 1 root root 2442001 2009-06-27 11:41 Tarantula-4.jpg
> -rwxrwxrwx 1 root root 2596930 2009-06-27 11:41 Tarantula-5.jpg
> -rwxrwxrwx 1 root root 3218977 2009-06-27 11:40 Tarantula.jpg
>
> I am able to read and delete files on the remote Win XP PC shared folder asus1/documents. The folder does not exist on this remote PC.
>
> At the start of the copy, Nautilus creates the folder "Tarantula", then terminates with the error: "Error while copying "Tarantula-1.jpg".
>
> The Tarantula folder on the remote PC (as reported from Nautilus 2.26.2 File Browser):
> Location: smb://asus1/documents/Tarantula
> Tarantula-1.jpg , size = 64.0 KB, type = JPEG Image, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
> .picasa.ini = 59 bytes, type = unknown, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
>
> It appears that the .ini file was copied completely, as I can open and read the file in a text editor. The JPEG image was partially copied when smb terminated. The problem can be repeated.
>
> This may be a problem with smb.
>
> ProblemType: Bug
> Architecture: amd64
> DistroRelease: Ubuntu 9.04
> ExecutablePath: /usr/bin/nautilus
> NonfreeKernelModules: nvidia
> Package: nautilus 1:2.26.2-0ubuntu2
> ProcEnviron:
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: nautilus
> Uname: Linux 2.6.28-13-ge...

ed@ed:/etc/samba$ dpkg-query -W smbclient
smbclient 2:3.5.4~dfsg-1ubuntu8.2

Still the same issue on ubuntu 10.10 x64

Will this be fixed for 10.04? I am a bit surprised to see that the samba package is not installed on my desktop:

$ sudo apt-get install samba
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  openbsd-inetd inet-superserver smbldap-tools ldb-tools
The following NEW packages will be installed:
  samba
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 6,822kB of archives.
After this operation, 18.4MB of additional disk space will be used.
Get:1 http://ca.archive.ubuntu.com/ubuntu/ lucid-updates/main samba 2:3.4.7~dfsg-1ubuntu3.3

Yet autofs seems to mount my SMB shares on the network (I have no shares on this machine) without a problem. However as noted above, the version of samba does not meet the same version that fixes this issue.

So I'm not sure if this is fixed for lucid LTS.

Yes I have to note this is a bug with gvfs on lucid.

Shares sporadically fail and work.

I have the same problem. Ubuntu 10.04 client, Windows Server 2008 R2 share.

I have the same problem on ununtu 12.04. It occurs after copying 1.4 GBytes of a 8.5 GByte file.

Nautilus in Ubuntu 8.04 has the ability to write to my SMB server.
I can not do this with Ubuntu 10.04. I have yet to test 12.04
The fast work around is to load GNOME COMMANDER to transfer your files.

> Date: Sun, 3 Feb 2013 09:57:47 +0000
> From: <email address hidden>
> To: <email address hidden>
> Subject: [Bug 393012] Re: [SRU] smb: Error while copying file, "Invalid argument"
>
> I have the same problem on ununtu 12.04. It occurs after copying 1.4
> GBytes of a 8.5 GByte file.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/393012
>
> Title:
> [SRU] smb: Error while copying file, "Invalid argument"
>
> Status in autofs - automatic filesystem mounter:
> Confirmed
> Status in GVFS:
> Unknown
> Status in Samba:
> Fix Released
> Status in “gvfs” package in Ubuntu:
> Fix Released
> Status in “samba” package in Ubuntu:
> Fix Released
> Status in “gvfs” source package in Maverick:
> Invalid
> Status in “samba” source package in Maverick:
> Fix Released
> Status in “gvfs” package in Debian:
> Fix Released
>
> Bug description:
> Binary package hint: nautilus
>
> While copying a folder from ubuntu to a Windows XP PC, I get an error
> message, "Error while copying "Tarantula-1.jpg".
>
> "There was an error copying the file into
> smb://asus1/documents/Tarantula." Show more details: Invalid argument
>
> The source folder is called "Tarantula", which contains:
> /host/Documents and Settings/All Users/Documents/Tarantula> ls -sail
> total 15545
> 112420 0 drwxrwxrwx 1 root root 0 2009-06-27 11:41 .
> 3856 4 drwxrwxrwx 1 root root 4096 2009-06-27 16:43 ..
> 112426 1 -rwxrwxrwx 1 root root 59 2009-06-27 11:40 .picasa.ini
> -rwxrwxrwx 1 root root 2622811 2009-06-27 11:41 Tarantula-1.jpg
> -rwxrwxrwx 1 root root 2565675 2009-06-27 11:41 Tarantula-2.jpg
> -rwxrwxrwx 1 root root 2449986 2009-06-27 11:41 Tarantula-3.jpg
> -rwxrwxrwx 1 root root 2442001 2009-06-27 11:41 Tarantula-4.jpg
> -rwxrwxrwx 1 root root 2596930 2009-06-27 11:41 Tarantula-5.jpg
> -rwxrwxrwx 1 root root 3218977 2009-06-27 11:40 Tarantula.jpg
>
> I am able to read and delete files on the remote Win XP PC shared
> folder asus1/documents. The folder does not exist on this remote PC.
>
> At the start of the copy, Nautilus creates the folder "Tarantula",
> then terminates with the error: "Error while copying
> "Tarantula-1.jpg".
>
> The Tarantula folder on the remote PC (as reported from Nautilus 2.26.2 File Browser):
> Location: smb://asus1/documents/Tarantula
> Tarantula-1.jpg , size = 64.0 KB, type = JPEG Image, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
> .picasa.ini = 59 bytes, type = unknown, group = unknown, Octal Permissions = unknown, Owner = unknown, Permissions = unknown
>
> It appears that the .ini file was copied completely, as I can open and
> read the file in a text editor. The JPEG image was partially copied
> when smb terminated. The problem can be repeated.
>
> This may be a problem with smb.
>
> ProblemType: Bug
> Architecture: ...

I'm not sure if I have the same issue but I'm getting the "Invalid argument" error message when I try to delete something from the samba share. I don't know about the copying problem, usually I don't copy anything from the smb share to the PC it's mounted on.

I can't find bug report for the deletion problem though.

This happens now on 18.04. I can use the shares from a Linux machine for several hours after reboot. But eventually it will stop working getting above error message.