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

[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.

[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.

[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

[Marc -Devoteam-]

Hi @Tanima Srivastava 

I'm no Linux admin, but the issues you have is file system permission related.

It's about;

Missing Permissions: the account lacks explicit allow or full control rights for the folder.

File Locks: Another application or process is actively using a file inside the directory.

Read-Only Attributes: Files or subfolders are marked as read-only or protected.

To me the look like you only have read permissions for Group Confluence.