Java File.setLastModified() fails on Linux when you are not the file owner

I have a java jar file which uses File.setLastModified() to set a specific time stamp for a file by referring to /mnt/nxx/file.name. It works as desired when the file is owned by the same UID as the logged-in user running the java process. But it fails if the logged-in user is any other UID.

The file is hosted on an external USB drive formatted with an Ext4 file system mounted on a Raspberry Pi at boot time via /etc/fstab using:

/dev/sdb1 /mnt/nxx ext4 defaults 0 2

An Ubuntu host on the same network, and which mounts the same disk at boot time via /etc/fstab using:

192.168.x.x:/mnt/nxx /mnt/nxx nfs rw 0 1

also can successfully set the time-stamp as long as the logged-in user has the same UID as on the Pi.

However, a Windows-10 host that connects via Samba to the same disk (mapped as N:\ to \ RASPI\root\mnt) and running the same java code can successfully set the time-stamp for ANY file regardless of the file owner as claimed by the Pi.

The file in question has 777 permissions and, as expected, any user on any host in my home network can successfully modify the file. The only issue is that the java call to setLastModified() fails when the UID of the user on the Linux hosts doesn’t match the file owner -- even if the user java process is running with the same GID as the file.

My goal is to be able to mount the disk and share it across all the hosts in my home network via whatever method so that both the Windows and Linux hosts on my home network can use the java code to successfully manipulate the time-stamps.

Why can Windows-10 successfully manipulate the time-stamp regardless of the user while Linux can not? Is there a way for me to add/configure options in the various fstab mount directives, in smb.conf, or elsewhere to configure the disk so that Linux will behave the same way Windows does?

BTW: The same issue exists with externally mounted HDDs formatted with NTFS file systems. I have not tried usermapping with the NTFS drives.

Any help would be appreciated.

cw

Here is some further information for those encountering this issue which I believe offers a viable work-around even if the underlying issue appears to remain.

The issue appears to manifest itself only when (1) the files in question are NOT owned by the UID of the running java process (Note: File read/write permissions are not the issue here, it is file ownership that matters,) and (2) the disk volume on which the files in question reside is mounted under a UID different from that of the file owner. Under those conditions, java fails to set the Last-Modified time as expected.

If the disk is mounted as CIFS or under a UID which matches that of the file owner, then java can successfully manage the time-stamps.

Also, this issue is manifest only on Linux hosts. Windows hosts do not appear to manifest this issue regardless of file ownership or file system.