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.

[Gabriela - LeanZero]

Hi @Tanima Srivastava, thanks for running it, but root is the one user that cannot fail that test, so the two zeros do not clear the filesystem yet. A process can always chmod a file it owns, and root owning the probe is exactly the case I was not asking about. The refusal I am chasing only happens for the uid the JVM actually runs as, on a file the mount reports as belonging to someone else. So the same probe has to run as that user, in the directory Confluence writes attachments to.

Two commands first, so we are pointing at the right thing:

ps -o pid,user,args -e | grep -i [j]ava | head -1
findmnt -T /var/atlassian/application-data/confluence/shared-home -o SOURCE,FSTYPE,OPTIONS

The first says whether the JVM is root as well or the usual 2002. The second says what that volume really is and with which uid, gid and file_mode; if findmnt is not in the image, stat -f -c %T . gives you the filesystem type. Then, as that user and in the attachments directory under the shared home:

su -s /bin/sh -c 'touch probe.png; ls -l probe.png; chmod +x probe.png; echo "+x=$?"; ls -l probe.png; chmod a-x probe.png; echo "-x=$?"; rm -f probe.png' <jvm user>

I had the ls in the wrong place in my first version, and your paste is where it shows. With one ls only at the end, a mount that applied both chmods and a mount that ignored them both finish on the same -rw-r--r-- with the same two zeros, because a-x puts a 755 file back to 644 anyway. Reading it straight after the +x is what separates those two.

Where this lands if the JVM is not root: mount.cifs defaults uid to 0, so on an SMB volume every file reads as root-owned, the pod at 2002 still writes the attachment because file_mode is permissive, and then it cannot chmod what it does not own. That refusal is your exception. Pinning uid and gid in the mountOptions to the JVM's uid is the cheap thing to try. Those modes are set at mount time rather than on the file. That is the reason Microsoft's own recommended storage class for Azure Files SMB on AKS carries dir_mode and file_mode at all, while their NFS class carries neither, NFS keeping real mode bits. Atlassian allows either, "NFS and SMB/CIFS shares are supported as the locations of the shared directory", so if the uid pin does not take, moving the shared home to NFS is the durable answer rather than a third mount option.