After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 327249 - nautilus ignores umask
nautilus ignores umask
Product: gnome-vfs
Classification: Deprecated
Component: File operations
Other All
: Normal normal
: ---
Assigned To: gnome-vfs maintainers
gnome-vfs maintainers
Depends on:
Reported: 2006-01-16 19:49 UTC by nahoo82
Modified: 2007-01-11 11:38 UTC
See Also:
GNOME target: ---
GNOME version: ---

Fix for nautilus 2.14.1 (765 bytes, patch)
2006-08-03 19:25 UTC, Josselin Mouette
none Details | Review
Fix for nautilus 2.16.0 (765 bytes, patch)
2006-10-02 16:53 UTC, Josselin Mouette
none Details | Review
Real fix for nautilus 2.16.0 (772 bytes, patch)
2006-10-04 15:31 UTC, Josselin Mouette
none Details | Review
Fix using target_default_perms (712 bytes, patch)
2006-12-08 21:58 UTC, Josselin Mouette
none Details | Review

Description nahoo82 2006-01-16 19:49:43 UTC
Fordwarded from


while trying to set a global umask for my users via gdm, I discovered 
that nautilus simply refuses to use any umask. Even when the session's 
umask is set to something non default and other gnome programs obey it 
(gedit, evolution,...), nautilus keeps on creating files with 600 as 

This makes it impossible to use nautilus in a network environment with 
shared folders.

Thanks for your tremendeous work,


I've tested this on nautilus 2.12, creating a .gnomerc with the needed umask, but nautilus always uses 600 as umask.
Comment 1 Christian Neumair 2006-01-16 20:13:00 UTC
Thanks for your bug report!

I'm reassigning this to GnomeVFS. We're hard-coding 0666 in gnome-vfs-xfer.c:xfer_create_target which is passed to gnome_vfs_create_uri, pass  0600 to fchmod in gnome-vfs-private-utils.c:gnome_vfs_create_temp, and pass 0777 to gnome_vfs_make_directory_for_uri in gnome-vfs-xfer.c:create_directory.

I think what permissions are used should be decided inside GnomeVFS. Maybe we should pass umask permissions, and the modules should decide whether they care or not.
Comment 2 Václav Svátek 2006-05-03 11:44:49 UTC
is anybody going to fix this bug?

From my point of view, it is making GNOME/nautilus unusable in the group/corporate environment- users can't share directories and files. Am I right?

Though, I believe that GNOME/nautilus is used for sharing files among users. Could you give me a tip how to do that?

Thank you,
Vaclav Svatek.
Comment 3 John Steele Scott 2006-05-24 12:17:10 UTC
Is there any workaround for this? There are people using GNOME in big organisations. How do they cope with this?
Comment 4 Julien Valroff 2006-06-17 15:54:34 UTC
You can try to use webdav for that purpose.
This is how gnome-user-share works, but it is really hard to use as very slow even in local, and most of GNOME apps do not support dav:// protocols (eg. I cannot open my pictures shared in a local folder via gthumb in Nautilus, I have first to copy the files to open them or have to use davfs2 to mount local shared folders which again has some limits...

Really, this bug should be fixed for the next GNOME release, as it prevents GNOME/nautilus use not in big organizations as said before, but also for simple (shared pictures, music etc.)


Comment 5 Al Gordon 2006-07-26 14:40:55 UTC
I now have 2 different corporate customers who are being affected by this problem. A bugfix would be great. :)
Comment 6 Al Gordon 2006-08-03 15:03:13 UTC
I just posted a bounty on this issue. Anyone want to make a quick $250 USD, jump on it:
Comment 7 Josselin Mouette 2006-08-03 19:25:15 UTC
Created attachment 70155 [details] [review]
Fix for nautilus 2.14.1

Here is a simple fix. The initial analysis turned out wrong, this is a nautilus bug. Copying a temporary file will result in the file creating with paranoid permissions, like those of a temporary file.
Comment 8 Al Gordon 2006-08-03 19:51:42 UTC
If it works, it will definitely be eligible for the bounty.

Is this going to find it's way into current official Ubuntu and Debian repositories, so that some future apt-get upgrade I do after patching doesn't undo everything?  I realize that I can create a custom deb and pin it, but that doesn't seem nearly as clean as seeing the change roll into official production, especially given the nature of thie fix, and the problem that it solves.
Comment 9 Josselin Mouette 2006-08-03 19:57:08 UTC
I've just uploaded a patched package to Debian unstable.
Comment 10 Julien Valroff 2006-08-04 05:05:23 UTC
Great! Thank you Josselin for your work.

However, the patched nautilus package still does not follow the default posix ACL from the parent folder.
Do you think it is possible to take this into account?

Comment 11 Julien Valroff 2006-08-04 05:22:44 UTC
Maybe I should have been more precise:
julien@hera:/home$ ls -ld partage/
drwxrwsr-x+ 2 root audio 4096 2006-08-04 07:20 partage/
getfacl partage/
# file: partage
# owner: root
# group: audio
julien@hera:/home$ ls -l partage/
total 0
-rw-r--r--  1 julien audio 0 2006-08-04 07:20 nouveau fichier
-rw-rw-r--  1 julien audio 0 2006-08-04 07:19 test

In this case, test was created in command line through touch.
"nouveau fichier" was created by nautilus thanks to the contextual menu "Create a document > Empty file" (or whatever it is called in English).

Given the default ACL, all the files created under partage/ should be writable by the audio group, which is not the case with nautilus.

Comment 12 Josselin Mouette 2006-08-04 08:19:28 UTC
Julien, I think this is feasible but it requires more important changes to the code. We need to replace the call to nautilus_file_operations_new_file_from_template by direct calls to gnome_vfs_async_create_uri and gnome_vfs_async_write. This would also fix the umask bug in a more elegant way.
Comment 13 Julien Valroff 2006-08-04 15:39:21 UTC
I wish I could write C and would do it myself ;-)

Do you think someone will do that shortly? I thought fixing this umask bug would also fix this. I really think both issues are linked.

Comment 14 Julien Valroff 2006-08-05 14:17:34 UTC

I have built latest gnome-vfs which includes ACL support, and applied the patch from #62817 ( - which applies to nautilus package from Debian unstable), and this does not work neither (same behaviour as explained before).

Should I open a new bug for this issue?

Comment 15 Josselin Mouette 2006-08-05 15:28:45 UTC
No, the issue is really the same, and the solution doesn't need any specific ACL support: nautilus shouldn't use a temporary file for the purpose of creating a file elsewhere, especially when gnome-vfs has all the functions to do that.
Comment 16 Jaume 2006-09-21 19:10:37 UTC
Hi Josselin,
I applied the patch and I have some strange behavior. If I set an umask of 007, I get files with permissions 661, but I should be getting 660.
I think the MODE XOR UMASK is not what you should do. I think it should be MODE AND !UMASK.
Correct me if I am wrong.
Thanks for your patch!
Comment 17 Josselin Mouette 2006-10-02 16:53:08 UTC
Created attachment 73864 [details] [review]
Fix for nautilus 2.16.0

Of course, it indeed needs to be &, not ^.
Comment 18 Josselin Mouette 2006-10-04 15:31:24 UTC
Created attachment 74009 [details] [review]
Real fix for nautilus 2.16.0

Ooops. This one was very wrong.
Comment 19 Mark 2006-11-11 16:06:32 UTC
i noticed this bug isn`t fixed in the most recent nautilus versions..
perhaps forgotten?
Comment 20 Alexander Larsson 2006-11-13 13:23:51 UTC
Changing the umask like that is not threadsafe. If a gnome-vfs workerthread was creating a file at the same time it'd get 000 as permissions.
Comment 21 Alexander Larsson 2006-11-13 13:28:13 UTC
Using GNOME_VFS_XFER_TARGET_DEFAULT_PERMS in the gnome-vfs-xfer call in this case seems a better solution.
Comment 22 Mark 2006-11-13 15:42:24 UTC
could you make a pactch file and attatch it here?
Comment 23 Josselin Mouette 2006-12-08 21:58:00 UTC
Created attachment 77992 [details] [review]
Fix using target_default_perms

This patch uses GNOME_VFS_XFER_TARGET_DEFAULT_PERMS instead. Julien, could you check whether it also fixes the problem with posix ACLs?
Comment 24 Julien Valroff 2006-12-09 11:10:22 UTC

I have applied successfully this updated patch to Debian unstable 2.14.3 sources. Everything seems to work ok with Posix ACLs!

Thank you very much for your work.

Comment 25 Alexander Larsson 2007-01-11 11:38:25 UTC
Commited. Thanks.