Can't save file to samba share

When I try to save a file from gmoccapy 3.0.8.2's internal editor (either to the original file, or to a new filename) to a mounted samba share, I get " OSError: [Errno 1] Operation not permitted: '[filename]' " (as seen below)



The file(s) and directory are owned by root, but world r/w/x (because ntfs is ugh), and I have no trouble creating/editing files there from the command line, with vim/gedit (all under the same username as I'm running linuxcnc), or even the editor in Axis.

Is this something broken in the software, or something I broke?

I'm open to suggestions and/or requests for further information, if it's likely to help.

-Bats

Compress the files and you can save.

@bats
I'm sorry I can't really help you there maybe norbert will answer this.


@tecno
He wants to save the code from inside the code editor of Gmoccapy. Saving it from outside the editor is not the problem.

Only way I can copy via Samba to a Win machine is to compress, Save a .py will not work for me anyways.

Aciera has it right. There's no problem copying files to/from the samba share, nor editing/saving files with other editors. Even using Axis's (semi)internal editor is just fine. It's not a matter of linux vs. win textfile formats, either (which I suppose might cause problems with .py files, from what little I remember about Python's use of whitespace). It's only gmoccapy's code editor that throws an error.

Interestingly enough, though, it looks like it's not a complete failure to write. When I try to save to a new file, it throws the "operation not permitted" error, but it looks like the file is still created and written to. Trying to save to the current file, on the other hand, gives "OSError: [Errno 2] No such file or directory" and doesn't update the file. I'll try to post a screenshot of that error a little later - I'm typing on the wrong PC right now.

-Bats

As promised, here's the error when using the "save the file using the original name" button:

annnd....

It looks like "save the file using the original name" will not only fail to update, but will actually destroy (or at least somehow mangle) the original file. Check out how test4.ngc behaves when I try to cat it in this screencap:



(and no, surprising though it may be, the file actually doesn't contain the text "cat: test4.ngc: No such file or directory").

Also, check out that "0" in the links filed on the ls -l... That was a "1" before I tried saving, which could definitely account for cat's trouble... but I have no idea why gmoccapy's editor would've borked it like that, or even how a file with zero hard links still exists at all.

Curiouser and curiouser.

And I'm way out of my depth here.

-Bats

Are you perhaps falling victim to Samba using SMB1 by default? Win10 turns that off (and it should be kept that way). This article might help change Samba config to use SMB2. www.cyberciti.biz/faq/how-to-configure-s...v1-on-linux-or-unix/
I have no direct experience with this combination yet, perhaps next week before I get to that stage with my set up.

Gerrit

gerritv wrote:

Are you perhaps falling victim to Samba using SMB1 by default?

Possible, but unlikely. I think. Probably. Maybe.

As far as I can tell (and I'll admit, my brain's been feeling pretty mushy lately) that link is only related to the samba server, while my problem is client-side. I don't think I even have smbd installed on this box, and the trouble is all with files being hosted on Win7/Win8 boxes.

I'm also having trouble understanding why a difference in protocol would only impact Gmoccapy's editor... but I suppose it'd hardly be the strangest thing I'd ever seen.

-Bats

safe_write tries to create a temp file , writes to it and then renames to the desired name so the error seems to be saying that the temp file did not get ccreated.
Have you tried using Axis or some other GUI? The safe_write function is used there as well. Or perhaps look at the ngc path in the gmoccapy ini files, the error mesaage is rather typically useless as it doesn't give values for the parameters. You might have to resort to the usual scripted language crutch of adding print statements to glade_vcp/hal_sourceview.py (linuxcnc/lib/python/gladevcp/hal_sourceview.py)

The file write mode for safe_write is 0x644