Can't save file to samba share

gerritv wrote:

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.

And yet it also seems to break the hard link to the original file, which, if that's the order of operations, has me puzzled.

Have you tried using Axis or some other GUI? The safe_write function is used there as well.

Yep. No problems editing or saving through Axis at all... But I was under the impression Axis just popped a gedit window, while Gmoccapy uses something more integrated-ish?

Or perhaps look at the ngc path in the gmoccapy ini files,

If you mean PROGRAM_PREFIX, then yes, that's pointing at a directory on the share - but that doesn't (and seemingly shouldn't) matter. If I navigate to work with a local file, it's fine. Navigate to somewhere else on the share, and it breaks again.

the error mesaage is rather typically useless as it doesn't give values for the parameters.

Figures.

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)

Ugh... I'm at least half a decade out from my coding days, and python was never one of my stronger languages to begin with. I may have to just give up and pop a terminal window with vi when I need to edit something.

Or maybe I'll feel braver tomorrow.

And at least I've got somewhere to start poking.

Thanks,
-Bats

So here's the function in question (thanks for giving me the needed kick in the bats to go looking at it, gerritv - it was more straightforward than I feared):
( from /usr/lib/python2.7/dist-packages/gladevcp/hal_sourceview.py )

It looks like the problem has nothing to do with creating the file... it's the chmod that kills it. Trying to chmod a file on a root-owned smb share as a non-root user gives "Operation not permitted" (and just silently fails when root tries it).

The question is, where do I go from here?

Just commenting out the chmod seems to make things work (the only apparent difference being that the files in local - permission-aware - filesystems end up as rw/-/- instead of rw/r/r), but that sets me up for trouble if an update comes along & breaks my "fix", and does nothing to resolve the issue for anyone else who finds themselves in the same mess.

Would it possible (or advisable) to just silently fail if the chmod fails, instead of throwing a tantrum? Does python allow nested try/catch blocks like that?

And should there be more checking done before unlinking (potentially deleting) the original file at the end, if this is going to be called "safe_write()"?

Any thoughts?

Or is there someone more qualified (read: even slightly qualified) that I can pass this off to?


-Bats

Maybe the real problem is that hte files are root in the first place? This link references why the chmod was added but seems to not quite do what is needed. github.com/LinuxCNC/linuxcnc/issues/82

Perhaps setting Samba up using force user/group will help resolve it? www.thegeekdiary.com/how-to-force-user-g...es-on-a-samba-share/
(I presently have no way to try this but I will need this to work once I get set up, hence my interest)

gerritv wrote:

Maybe the real problem is that hte files are root in the first place?

That bothers me a bit too (although I suppose technically the files aren't root, just the share is mounted by root) - although it seemed to be the default I ended up with when setting the box up (up until I started trying to migrate to linuxCNC, I'd been away from linux for nearly as long as from coding, and I'm discovering it's absolutely nothing at all like riding a bicycle). My gut feeling, though, is that the problem is chmod'ing files on samba shares in general, rather than the owner of said shares. The fact that even root can't do a chmod (it just fails more quietly) would seem to hint in that direction.

This link references why the chmod was added but seems to not quite do what is needed. github.com/LinuxCNC/linuxcnc/issues/82

Yeah... looks like it was an easy bandaid at the time, but now it's getting infected. Ew.

(not that I wouldn't have been inclined to do exactly the same thing)

Perhaps setting Samba up using force user/group will help resolve it? www.thegeekdiary.com/how-to-force-user-g...es-on-a-samba-share/
(I presently have no way to try this but I will need this to work once I get set up, hence my interest)

I'll have to spend more time swearing at staring at the article and playing with it, and see if anything sensible shakes loose... or if I can figure out exactly why I got stuck with root owning the shares in the first place.


-Bats

andypugh wrote:

How are you navigating to the samba share?

I'm using gmoccapy's internal browser & going straight to /media/[share]/[path], where fstab mounts the share. Is there an alternative?

Years ago I found that the only way to make it work was to go via the "gvfs" folder where Linux mounts Samba shares.

I didn't even realize Xfce used gvfs... Although I suppose Thunar must have something of the sort, since it seems to have its own private mounts that I could never find from the command line.

-Bats

So it looks like I could get the share to mount as user:user by adding ,uid=1000,gid=1000 to the fstab line. While this is a good thing in itself, it looks like it only half-solves (or half-works-around) the saving problem.

Saving a new file to a share mounted this way (at least as long as the share owner is the same user linuxcnc is running as - I haven't tried any other scenarios) works without an error (yay!)... but trying to save to the existing file still complains - although this time it's the os.rename() that it dies on, instead of os.chmod(), and I'm not sure why.

Still digging.

-Bats
[edit: it should be noted that bats are not known for their burrowing prowess]

Last update for the night... when entered line by line in the python interpreter, everything seems to work fine (at least with the new user-owned share - the root-owned one still borks on chown)... so I'm at a complete loss for why it's breaking when the application tries it.

Also, I'd made some incorrect assumptions earlier about what the os.unlink was unlinking (and some possibly disparaging & probably unwarranted remarks about the "safety" of safe_write). It looks like that's just a cleanup of the temp file - so something else apparently causes the delinking of the original file. I don't understand that bit, either.


-Bats

andypugh wrote:

[edit: it should be noted that bats are not known for their burrowing prowess

www.batcon.org/resources/media-education...zine/bat_article/228

That's uncle Henry. Should've known someone would bring up his branch of the family. We don't discuss them. Nesting in rotten logs? Filthy! And that whole "walking" thing is just plain undignified.

But, while we're talking about digging anyhow... On a whim/following a lead, I decided to try replacing os.rename() with shutil.move(), annnnd...

...that didn't work either.


One possible workaround - although I couldn't find anything in the docs... I know Axis is supposed to be able to use vi - Is there any way to use an alternative editor with Gmoccapy?
This time it looks like it's specifically the destination file that it's having trouble finding - suggesting the removal of the hard link had already happened by the time the rename rolls around.

There's definitely something ugly happening between the rename process(es) and the samba share, but I'll be damned if I can figure out what it is. After spending the day struggling with this, I've pretty much hit a wall. I just don't know that I understand python or linux well enough at this point to make much progress. I'd already been forced to resort to trial and error, and now I've pretty much run out of errors to try.

Any other suggestions, ideas, or sheer random guessing?

[ edit: One possible workaround - although I couldn't find anything in the docs... I know Axis is supposed to be able to use vi - Is there any way to use an alternative editor with Gmoccapy? ]


-Bats
(not the digging kind, more's the pity)