Gnome Remote Server applet modifies file permissions

Bug #71229 reported by Brice Terzaghi
2
Affects Status Importance Assigned to Milestone
gnome-vfs2 (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

I use the Gnome "Remote Server" applet to manage several web sites : I mount the FTP server to my desktop so that I can browse it like a local drive.

I'm not sure the applet is named "Remote Server" as I use Ubuntu in French : in my language it is called "Se connecter à un serveur distant".

It worked flawlessly in Dapper Drake but has a big problem in Edgy Eft. I'm not sur if it's a bug from Gnome 2.16 or its integration in Ubuntu.

The problem is simple : whenever I transfer files to a FTP server with this applet, it adds write access rights to anyone. I.e. if I upload a file that has a chmod of 644 (read for everyone / write for owner), it is set to 666 server-side.

It is reproducible for every file I upload from Edgy (even using the LiveCD, so it's not related to a modification of my installed system). Files uploaded from the Dapper LiveCD keep their permissions.

This behaviour leads to another problem which I've been able to reproduce only with one french web hosting provider and I'm not sure of what is happening (because I don't have access to the server's logs) : after a PHP file has been uploaded on this particular provider's server, it seems to keep its permissions server-side but is inaccessible. After the permissions are manually modified with another FTP client, the file is accessible.

I don't know how/why this happens, but I can reproduce the behaviour explained in the first part of the message.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug. Do you have the same behaviour using gnomevfs-copy from a command line? What about when using the ftp command?

Changed in gnome-applets:
assignee: nobody → desktop-bugs
importance: Undecided → Medium
status: Unconfirmed → Needs Info
Revision history for this message
Brice Terzaghi (terzag) wrote :

I'm not a command-line power-user and I tend to prefer graphical applications when available. :/

In fact I don't even know what gnomevfs-copy is. Is it the command used by the Remote server applet ? How do I use it to make a test (i.e. where/how do I copy a file with it : on a FTP server, locally...) ?

The same goes for the ftp command : I'll first have to remember my student time ten years ago before I can make a test. :)

All I can tell for now is that I've stopped using the Gnome applet to transfer file and use the FireFTP extension for Firefox. It works flawlessly, even with the web provider (OVH) whose servers have a strange behaviour.

Revision history for this message
Daniel Holbach (dholbach) wrote :

Try to open a terminal, then run
     gnomevfs-copy <file> <ftp server url>

Revision history for this message
Brice Terzaghi (terzag) wrote :

Same problem. The original file has permissions 0644 (r for everyone, w for owner) and when copied with gnomevfs-copy, it gets 0666.

Changed in gnome-vfs2:
status: Needs Info → Unconfirmed
Revision history for this message
Sebastien Bacher (seb128) wrote :

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

Changed in gnome-vfs2:
importance: Medium → Low
status: New → Invalid
status: Invalid → Incomplete
Revision history for this message
Brice Terzaghi (terzag) wrote :

It works better but not completely as expected, although it may be related to the server.

I just uploaded a PHP file with 644 permission on an OVH server (OVH is the provider I had problem with). I don't have the PHP problem anymore (the file executes fine) but my file now has permissions 604 (no rights for group). The same behaviour happens with FireFTP (Firefox extension). Also, it doesn't happen with my account on another provider's server (the files keeps 644), so I guess it's an issue with server-side settings at OVH.

Seems to be fixed to me.

Revision history for this message
Sebastien Bacher (seb128) wrote :

thank you for the update, closing the bug

Changed in gnome-vfs2:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.