Skip to main content
T
tmikes
February 5, 2026
Question

CFFILE not deleting "read-only" files

  • February 5, 2026
  • 2 replies
  • 117 views

I have a simple loop that is used to clean up old files within a directory:

​<cfdirectory action="list" name="qDir" directory="#variables.path#">
<cfloop query="qDir">
	<cfif qDir.Type eq "File">
		<cfif DateDiff("h", qDir.DateLastModified, Now()) gt attributes.keep_for_hours>
			<cfset variables.full_file_path = variables.path & qDir.Name>
			<cfif FileExists(variables.full_file_path)>
				<cffile action="delete" file="#variables.full_file_path#">
			</cfif>
		</cfif>
	</cfif>
</cfloop>

This is on Linux where ColdFusion is running as apache.
Recently a system scan process has been leaving behind files owned by root within the directory resulting in an error stating:
“The file or directory <filename> provided as the Source is read-only. - The Delete cannot be performed.”
While it’s true that the file is read-only, apache owns the directory the file is in and should still be able to delete the file.
How do I go about encouraging CFFILE to remove the file anyway?

    2 replies

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    February 6, 2026

    Apparently, your ColdFusion installation does not have w+x permissions on the directory from which the read-only files are to be deleted. So, the error message is correct.

    Note that ColdFusion does not and cannot run “as Apache” on Linux. It always runs as its own Java Virtual Machine, that is, as a separate user in Linux, even when integrated with Apache.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    February 5, 2026

    While someone else may have a different take, I’d start with confirming your current assumptions about the user running CF, and then about the permissions on the file itself (rather than the folder).

     

    You can see both those from within CF with this code. Note there are two aspects of getting the file info, first literally getfileinfo (which confirms things like the readonly mode) but then using cfdirectory to get the permissions (offered via the filemode, only on Linux). I show both, with the latter using a Q of Q to focus on just a given file in a given folder (defined at the outset, in a var whose value you should change). 

     

    You could of course fold this into your own code (already looping over cfdirectory), but faster would be to just drop it in a template, point to the path/file in question, and see what it reports. :-) Otherwise, perhaps the code may help someone else in the future. (And I offered it as tags, since that’s what you used. A script fan can of course convert it to cfscript with Pete F’s sweet cfscript.me site.)

     

    Let us know what you find, even if only confirmation of your assumptions.

    <cfoutput>
    Account running cf: #server.system.properties["user.name"]#

    <cfset filename="/yourpath/yourfilename" >

    <p>GetFileInfo for #filename#:
    <cfdump var="#GetFileInfo(filename)#">
    </cfoutput>

    <cfif server.os.name does not contain "Windows">
        <!--- The file mode cannot be obtained using cfdirectory in Windows --->
        <cfdirectory directory="#getdirectoryfrompath(filename)#" name="cfdir" >

        <cfquery dbtype="query" name="getfile">
            select mode from cfdir
            where Name='#getfilefrompath(filename)#'
        </cfquery>

        <cfoutput>
        <p>File mode for #filename#: #getfile.mode# 
        </cfoutput>
    </cfif>

     

    /Charlie (troubleshooter, carehart. org)
      T
      tmikesAuthor
      February 19, 2026

      Thank you, Charlie,
      The results were as follows, intermingled with my own commentary:

      Account running cf: apache

      I believe this confirms my assumption.

      GetFileInfo for <file>:
      canRead  YES
      canWrite  NO
      isHidden  NO

      No surprises here.

      File mode for <file>:

      I think I’d call this one “unexpected” but not “surprising”.  When I cfdump the cfdir object, Mode has [empty string] for every row.  Additionally, I queried and dumped the parent directory and received the same [empty string] results.
      Since I have access to the file system, I can confirm that the file is 644 root:root, and that the directory is 775 apache:foo (foo representing select users that have access to the production server).

       

      To reiterate the issue, regardless of canWrite being NO, I should still be able to remove the file since “I” as apache own the directory.  In fact, this works:

      <cfif fileExists(filename)>
          <cfexecute name="rm" arguments="#filename#">
      </cfif>

      I would just prefer to use cffile over cfexecute for security reasons that I am sure are obvious to you. 

        Charlie Arehart
        Community Expert
        Charlie ArehartCommunity Expert
        Community Expert
        February 19, 2026

        <==STRIKE>Well, the fact that Cfdirectory doesn't show any mode value might be a clue, since on Linux it should.</STRIKE==> (I want to revoke my first sentence here but sadly the new forum system doesn’t let us use an html strikeout indicator, nor can we edit the HTML. I found on closer reading of cfdirectory that even on LINUX the mode value is no longer populated.)

         

        The fact that the canwrite is NO seems to be the issue.

         

        Maybe it's indeed because (as you noted originally) the file is owned by root but cf is (as you confirmed) running as apache. I know you said that apache user owns the folder but maybe that's an issue. 

         

        I'm on a mobile as I write so can't test things. (Have you tried on anything other than the current cf instance and machine?) 

         

        More important, on this machine, can you have your cfexecute run whoami? I'd expect that it should report apache as well, which would then more clearly support your question of why cffile can't delete it (running as the same user). But let's not presume it will report apache: let's confirm.

         

        Once you do, I or someone else may offer more. BTW, Adobe may not reply here so if you feel it's a bug, either report it at tracker.adobe.com or send email to cfsup@adobe.com. You could share here the bug ID if you use tracker.

        Also, please tell us what cf version and update you're on, as it may be significant. That's shown in a dump of server.coldfusion.

        /Charlie (troubleshooter, carehart. org)
          Terms & ConditionsAccessibility statement
          Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices