Skip canWrite checks

TheGoesen

I am running the official docker image using adoptopenjdk. I was trying to get the confluence data directory mounted from a nfs share.

Confluence doesn't start in this setup. It claims its home directory is not writeable, even though it is. If you mount the  homedirectory from the host directly (hostpath in kubernetes) it works.

I tried to debug this behaviour and it seems to me that the java incorrectly returns false for File#canWrite. See code and output below: The code is able to create a files and locks, but canWrite always returns false

Basically in this setup everything works fine, just canWrite returns false for some odd reason.

This has happened to other people as well.

https://community.atlassian.com/t5/Confluence-questions/K8S-Confluence-cannot-write-to-home-directory-but-it-can/qaq-p/752886#M101684

https://community.atlassian.com/t5/Confluence-questions/K8s-Confluence-cannot-write-to-home-directory-folder-permissions/qaq-p/752888

 

Debugging this further requires diving in the c code of the jvm, Linux, kubernetes and maybe even nfs?.

 

Is there an Option in confluence to not check File#canWrite? Could such an option be added, does someone has a better idea?

 

final File test1 = new File("test");
test1.deleteOnExit();
final boolean test = test1.createNewFile();
System.out.println(Paths.get(".").toFile().canExecute());
System.out.println(Paths.get(".").toFile().canRead());
System.out.println(Paths.get(".").toFile().canWrite());
System.out.println(Files.isWritable(Paths.get(".")));
final PosixFileAttributes basicFileAttributes = Files.readAttributes(Paths.get("."),
                                                                     PosixFileAttributes.class);
for (PosixFilePermission permission : basicFileAttributes.permissions()) {
    System.out.println("permission = " + permission);
}
final UserPrincipal owner = basicFileAttributes.owner();
System.out.println("basicFileAttributes = " + owner);

final FileSystem fileSystem = Paths.get(".").getFileSystem();
final UserPrincipal userPrincipal = fileSystem.getUserPrincipalLookupService().lookupPrincipalByName(System.getProperty(
"user.name"));
System.out.println("userPrincipal = " + userPrincipal);
System.out.println(" = " + userPrincipal.equals(owner));
System.out.println("fileSystem = " + fileSystem);
System.out.println("setWriteable " + new File(".").setWritable(true, false));
System.out.println(Paths.get(".").toFile().canWrite());



try (final RandomAccessFile fileInputStream = new RandomAccessFile(test1, "rw")) {
final FileLock lock = fileInputStream.getChannel().lock();
    System.out.println("lock = " + lock);
    System.out.println("lock = " + lock.isValid());
}finally {
    test1.delete();
}

true
true
false
false
permission = GROUP_WRITE
permission = OWNER_READ
permission = OWNER_WRITE
permission = OWNER_EXECUTE
permission = OTHERS_WRITE
basicFileAttributes = daemon
userPrincipal = daemon
= true
fileSystem = sun.nio.fs.LinuxFileSystem@70dea4e
setWriteable true
false
lock = sun.nio.ch.FileLockImpl[0:9223372036854775807 exclusive valid]
lock = true 

 

TheGoesen

It turned out that all i needed to do was to change the owner/permissions of the parent directory on the nfs share.

This change doesn't matter for actual file operations, as they work out of the box. But it fixes this weird confluence/ File#canWrite thing

So if you are stuck with confluence claiming to be unable to write to the directory even though it is, change the owner and permissions of the parent directory on your nfs share.

/cynism this might not be supported in some cases but I have not seen any technical reason as of yet. There are some ancient claims that nfs+lucene might reduce performance in some circumstances and problems specific to  windows.