Bug ID: JDK-8261790 (zipfs) Files.setPosixFilePermission does not work with CIFS share

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

Other
tbdUnresolved

The fix to JDK-8229888 doesn't work on e.g. CIFS share, a directory mounted on a Linux with mount.cifs from a Windows server (which is a reverse configuration to the reported in discussion for that bug). There are plenty of these everywhere: Azure shares, corporate NASes exported in CIFS etc. A non-root account  could do almost anything there but an attempt to set Unix permissions would fail with non-zero exit status.

Now, exactly this happens in ZipFileSystem::sync() : 
        if (attrs != null) {
            Files.setPosixFilePermissions(tmpFile, attrs.permissions());
        }
Attribute view of this CIFS share is supported but not fully. As a result, there is a java.nio.file.FileSystemException and updating of a zip file totally fails. 

It's a regression. Fix is, I think, to catch and ignore java.nio.file.FileSystemException.

CIFS spec at https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-cifs/d416ff7c-c536-406e-a951-4f04b2fd1d2b no indication of POSIX file attributes (or similar) from what I see.
17-02-2021
I think we need to establish if is alway true that a "cifs" file system does not support POSIX file attributes. If so then we should change LinuxFileStore supportsFileAttributeView/supportsFileAttributeView to return false for this case (there is an inconsistent with the changes of "vfat" that can be examined at the same time).
16-02-2021
Ouch! I'm sorry I reverted your edit of the title by mistake :-) I'll add some details to this comment. A share I have is like this //nas/yan on /shared type cifs (rw,relatime,vers=3.1.1,cache=strict,username=yan,domain=CORP,uid=0,noforceuid,gid=0,noforcegid,addr=10.10.x.x,file_mode=0777,dir_mode=0777,soft,nounix,serverino,mapposix,rsize=4194304,wsize=4194304,bsize=1048576,echo_interval=60,actimeo=1) but a customer of mine has Azure and RHEL, also with file_mode and dir_mode set, and I guess nounix.
16-02-2021
[~yan] Would it be possible to paste in the df output or mount table entry for this file system? I suspect LinuxFileStore supportsFileAttributeView/supportsFileAttributeView may need to test this file system type. The zip provider could then test if the FileStore supports POSIX file attributes.
16-02-2021