nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unable to add any atttachments in a page

Tanima Srivastava

Hi Team,

We recently migrated to AKS from VM. Everything seems to be working fine , but when I am trying to add any attachment in the confluence page , it is throwing error "Cannot save the attachment as it contains an executable" , error , though I am uploading .png files. Still this is happening Following is the error:

com.atlassian.confluence.pages.persistence.dao.filesystem.AttachmentDataFileSystemException: Cannot save the attachment as it contains an executable file.
at com.atlassian.confluence.impl.pages.attachments.filesystem.ContentDirectoryStructureAttachmentDataFileSystemV004.restrictPermissionAndDeleteOnFailure(ContentDirectoryStructureAttachmentDataFileSystemV004.java:124)
at com.atlassian.confluence.impl.pages.attachments.filesystem.ContentDirectoryStructureAttachmentDataFileSystemV004.saveAttachmentData(ContentDirectoryStructureAttachmentDataFileSystemV004.java:113)
at com.atlassian.confluence.impl.pages.attachments.filesystem.FileSystemAttachmentDataDao.saveDataForAttachment(FileSystemAttachmentDataDao.java:142)
at com.atlassian.confluence.impl.pages.attachments.filesystem.FileSystemAttachmentDataDao.saveDataForAttachment(FileSystemAttachmentDataDao.java:117)

Any idea as to why this is happening

The file I am uploading is .png

Accepted answers

All comments

Marc -Devoteam-

HI @Tanima Srivastava

Check the permissions on the instance Confluence is running does the user running Confluence have correct permissions on the file location to create and write files?

Tanima Srivastava

yes , user has Administrator permissions , in the front end , it throws error

: Cannot save the attachment as it contains an executable file....

but I am upload .png extension.

Marc -Devoteam-

Hi @Tanima Srivastava

I'm not talking about the Jira users, but the users that runs Confluence on the server. Attachments are stored on the server file system. The user who runs Conlfeunce as this user read/write permissions on the file system

Check this with your server/system admins.

Gabriela - LeanZero

Hi @Tanima Srivastava, that error has nothing to do with the png. The frame it comes from, restrictPermissionAndDeleteOnFailure, does not read the file at all. I pulled confluence-10.2.15.jar off Atlassian's public maven repo and disassembled that class: on Linux the method it calls is a single line, file.setExecutable(false, false), and Confluence deletes the attachment it wrote and throws that exception when the call comes back false. It is reporting a failed chmod in wording that describes something else. Your line numbers double as a version fingerprint, since V004:113 and :124 exist in 10.0.1 through 10.2.15 and in none of the 9.x jars I checked, so you are on Confluence 10. Nothing Atlassian publishes describes this, so take it as me reading the jar rather than a documented source.

Marc is on the right layer, it is the filesystem. The write itself already succeeded though, and this exception is what proves it, because the bytes reach the disk before this step runs and a directory Confluence could not write to fails earlier with a different error. What gets refused is the chmod afterwards.

So the question is whether your pod can chmod a file it has written. Run this inside the pod, as the container's own user, in the attachments directory under the shared home:

touch probe.png; chmod +x probe.png; echo "+x=$?"; chmod a-x probe.png; echo "-x=$?"; ls -l probe.png; rm -f probe.png

Both directions and both exit codes are deliberate. Shell chmod skips the syscall when the mode would not change, so a lone chmod a-x on a file that has no x bit exits 0 and tells you nothing, while Java issues the call regardless. A non-zero on either line is your bug, reproduced outside Confluence.

What is backing that PVC, and with what mountOptions? That decides the fix and I cannot see it from here. If it is Azure Files over SMB, I would test ownership first: mount.cifs defaults uid to 0, and the client runs its own check, a "vfs_permission check of uid and gid of the file against the mode and desired operation", so a pod running as 2002 does not own the file it wrote and the chmod is refused before it ever reaches the server. Pinning uid=2002,gid=2002 in the mountOptions is the cheap thing to try, 2002 being the uid Atlassian's own Kubernetes KB tells you to chown that volume to. That half is inference from the mount options rather than something I have reproduced on AKS.

Tanima Srivastava

Hi,

The pod is running as a root user , I verified , inside the pod I ran these commands:

and here is the outpu

$touch probe.png; chmod +x probe.png; echo "+x=$?"; chmod a-x probe.png; echo "-x=$?"; ls -l probe.png; rm -f probe.png
+x=0
-x=0
-rw-r--r-- 1 root confluence 0 Aug 21 08:17 probe.png

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

data-center

confluence-data-center