<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	
	>
<channel>
	<title>Comments on: A solution to the umask problem: inotify to force permissions</title>
	<atom:link href="http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions/feed" rel="self" type="application/rss+xml" />
	<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions</link>
	<description></description>
	<lastBuildDate>Tue, 15 Mar 2022 14:49:21 +0000</lastBuildDate>
		<sy:updatePeriod>hourly</sy:updatePeriod>
		<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.7.1</generator>
	<item>
		<title>By: vskubriev</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-458</link>
		<dc:creator><![CDATA[vskubriev]]></dc:creator>
		<pubDate>Mon, 24 Mar 2014 12:48:40 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-458</guid>
		<description><![CDATA[I encountered the same problem with ATTRIB event&#039;s]]></description>
		<content:encoded><![CDATA[<p>I encountered the same problem with ATTRIB event&#8217;s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: vskubriev</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-457</link>
		<dc:creator><![CDATA[vskubriev]]></dc:creator>
		<pubDate>Mon, 24 Mar 2014 12:47:40 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-457</guid>
		<description><![CDATA[dear Alecz!
Nautilus is working on his own cunning scenario - I am agree with this. But sleep 1 - this is not a good solution, because we get timeout for each file/dir for a 1 second (as is in you example).
This is a very significant reduction in performance.]]></description>
		<content:encoded><![CDATA[<p>dear Alecz!<br />
Nautilus is working on his own cunning scenario &#8211; I am agree with this. But sleep 1 &#8211; this is not a good solution, because we get timeout for each file/dir for a 1 second (as is in you example).<br />
This is a very significant reduction in performance.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alecz</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-426</link>
		<dc:creator><![CDATA[Alecz]]></dc:creator>
		<pubDate>Mon, 06 Jan 2014 16:04:33 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-426</guid>
		<description><![CDATA[I had trouble getting this to work when Using Nautilus to transfer files over to an NFS share.
It would only work when creating new Folders, but not when copying/moving.

So I did some digging and here is the command that works (note that I have not used the one for trailing spaces or backstlashes:

****************************************
inotifywait -mrq -e CREATE -e CLOSE -e MOVED_TO --format %w%f /home/alex/autochown/ &#124; while read FILE; do `sleep 1` &amp;&amp; chmod g=u &quot;$FILE&quot;; done
****************************************
Explanations of modifications:
-e CLOSE and -e MOVED_TO are the last events that Nautilus does when creating new files or copying/moving files around. This way, permissions are set after Nautilus finished the copy.

the &quot;sleep 1&quot; is because when Nautilus creates a file, it changes the permissions right away. The issue is that the NFS server machine will get into a &quot;race condition&quot; and will change the permissions a few milliseconds before Nautilus will (all this happens in less than 0.5 seconds).

To work around this, we add a 1 second delay to the chmod command. This might only be a problem is the rate at which files are created in the folder is more than 1 per second for a very long time.]]></description>
		<content:encoded><![CDATA[<p>I had trouble getting this to work when Using Nautilus to transfer files over to an NFS share.<br />
It would only work when creating new Folders, but not when copying/moving.</p>
<p>So I did some digging and here is the command that works (note that I have not used the one for trailing spaces or backstlashes:</p>
<p>****************************************<br />
inotifywait -mrq -e CREATE -e CLOSE -e MOVED_TO &#8211;format %w%f /home/alex/autochown/ | while read FILE; do `sleep 1` &amp;&amp; chmod g=u &#8220;$FILE&#8221;; done<br />
****************************************<br />
Explanations of modifications:<br />
-e CLOSE and -e MOVED_TO are the last events that Nautilus does when creating new files or copying/moving files around. This way, permissions are set after Nautilus finished the copy.</p>
<p>the &#8220;sleep 1&#8243; is because when Nautilus creates a file, it changes the permissions right away. The issue is that the NFS server machine will get into a &#8220;race condition&#8221; and will change the permissions a few milliseconds before Nautilus will (all this happens in less than 0.5 seconds).</p>
<p>To work around this, we add a 1 second delay to the chmod command. This might only be a problem is the rate at which files are created in the folder is more than 1 per second for a very long time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Boubou</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-132</link>
		<dc:creator><![CDATA[Boubou]]></dc:creator>
		<pubDate>Wed, 05 Jun 2013 17:00:22 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-132</guid>
		<description><![CDATA[&lt;p&gt;@Rchard and myself&lt;br /&gt;
If using -e attrib, it loops.&lt;br /&gt;
chmod = modification of attrib =&gt; chmod...&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>@Rchard and myself<br />
If using -e attrib, it loops.<br />
chmod = modification of attrib =&gt; chmod&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Boubou</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-131</link>
		<dc:creator><![CDATA[Boubou]]></dc:creator>
		<pubDate>Wed, 05 Jun 2013 14:38:19 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-131</guid>
		<description><![CDATA[&lt;p&gt;@Richard&lt;br /&gt;
You can use -e move -e attrib to avoid this problem&lt;br /&gt;
-e move : check the files moved or renamed&lt;br /&gt;
-e attrib : check the files which permissions where changed&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>@Richard<br />
You can use -e move -e attrib to avoid this problem<br />
-e move : check the files moved or renamed<br />
-e attrib : check the files which permissions where changed</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-130</link>
		<dc:creator><![CDATA[Richard]]></dc:creator>
		<pubDate>Thu, 29 Nov 2012 15:14:55 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-130</guid>
		<description><![CDATA[&lt;p&gt;Nice script, but most clients will first transfer the file and then try to set the correct permisions so only watching for create will not do the trick.&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Nice script, but most clients will first transfer the file and then try to set the correct permisions so only watching for create will not do the trick.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: hatul</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-129</link>
		<dc:creator><![CDATA[hatul]]></dc:creator>
		<pubDate>Tue, 22 May 2012 08:59:56 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-129</guid>
		<description><![CDATA[&lt;p&gt;Thanks for the post&lt;/p&gt;


&lt;p&gt;For Centos you need to add after first line:&lt;br /&gt;
###&lt;br /&gt;
# chkconfig: 2345 98 55&lt;br /&gt;
# description: Manages the services you are controlling with the&lt;br /&gt;
chkconfig command&lt;br /&gt;
###&lt;/p&gt;


&lt;p&gt;and then:&lt;br /&gt;
chkconfig --add inotifywait.sh&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Thanks for the post</p>
<p>For Centos you need to add after first line:<br />
###<br />
# chkconfig: 2345 98 55<br />
# description: Manages the services you are controlling with the<br />
chkconfig command<br />
###</p>
<p>and then:<br />
chkconfig &#8211;add inotifywait.sh</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ölbaum</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-128</link>
		<dc:creator><![CDATA[Ölbaum]]></dc:creator>
		<pubDate>Wed, 25 Apr 2012 14:16:42 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-128</guid>
		<description><![CDATA[&lt;p&gt;Nah, incron won’t be any use because it doesn’t watch subdirectories. inotifywait is the way to go, thanks.&lt;/p&gt;


&lt;p&gt;It’s kinda pathetic that it’s needed, though. I tried the umask and acl routes, but they both fail one way or the other with samba, netatalk and/or sftp.&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Nah, incron won’t be any use because it doesn’t watch subdirectories. inotifywait is the way to go, thanks.</p>
<p>It’s kinda pathetic that it’s needed, though. I tried the umask and acl routes, but they both fail one way or the other with samba, netatalk and/or sftp.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Marc</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-127</link>
		<dc:creator><![CDATA[Marc]]></dc:creator>
		<pubDate>Wed, 09 Mar 2011 22:10:07 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-127</guid>
		<description><![CDATA[&lt;p&gt;Merci ! j&#039;ai corrigé la coquille.&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>Merci ! j&#8217;ai corrigé la coquille.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yannick Duchêne (Hibou57)</title>
		<link>http://positon.org/a-solution-to-the-umask-problem-inotify-to-force-permissions#comment-126</link>
		<dc:creator><![CDATA[Yannick Duchêne (Hibou57)]]></dc:creator>
		<pubDate>Wed, 09 Mar 2011 20:45:16 +0000</pubDate>
		<guid isPermaLink="false">http://positon.org:81/?p=102#comment-126</guid>
		<description><![CDATA[&lt;p&gt;« le bit setuid au groupe pour tous les dossiers.&lt;br /&gt;
find /path/to/dir -type d -exec chmod g+s {} \; » :&lt;/p&gt;


&lt;p&gt;La commande indiquée fixe le bit SGID, et non pas le bit SUID ;)&lt;/p&gt;]]></description>
		<content:encoded><![CDATA[<p>« le bit setuid au groupe pour tous les dossiers.<br />
find /path/to/dir -type d -exec chmod g+s {} \; » :</p>
<p>La commande indiquée fixe le bit SGID, et non pas le bit SUID ;)</p>
]]></content:encoded>
	</item>
</channel>
</rss>
