"java.io.IOException: Operation not supported" occurs on Mac / Samba-share


(Mike Mitterer) #1

On my Mac (10.8.3) this little script:

gradle --info -q upper

task upper << {
    String someString = 'mY_nAmE'
    println "Original: " + someString
    println "Upper case: " + someString.toUpperCase()
}

produces:

FAILURE: Build failed with an exception.

  • What went wrong: Could not open task artifact state cache (/Volumes/programming/DevJava/WebApp.Base/.gradle/1.7-20130529220026+0000/taskArtifacts). > java.io.IOException: Operation not supported

(The same result with 1.6)

This works: gradle --project-cache-dir /tmp -q upper

My project sits on a network drive (samba share) All the rights are properly set.


(Zou Guangxian) #2

I also encountered this problem today.

The directory was mounted with command

mount_smbfs -f 0664 -d 0775 //zouguangxian@host/x$ ~/Volumes/X

In the project directory, execute “gradle tasks” will failed with “java.io.IOException: Operation not supported”

[zouguangxian@]$ gradle tasks
[zouguangxian@]$ ls -la .gradle/1.6/taskArtifacts
total 64
drwxrwxr-x
1 zouguangxian
staff
16384
6
1 21:53 .
drwxrwxr-x
1 zouguangxian
staff
16384
6
1 21:53 ..
-rw-rw-r--
1 zouguangxian
staff
    0
6
1 21:53 cache.properties.lock

But if I execute “gradle --project-cache-dir /tmp tasks” like you suggests, it will succeed.

[zouguangxian@]$ gradle --project-cache-dir /tmp tasks
[zouguangxian@]$ ls -la /tmp/1.6/taskArtifacts/
total 96
drwxr-xr-x
6 zouguangxian
wheel
  204
6
1 21:08 .
drwxr-xr-x
3 zouguangxian
wheel
  102
6
1 21:08 ..
-rw-r--r--
1 zouguangxian
wheel
   30
6
1 21:08 cache.properties
-rw-r--r--
1 zouguangxian
wheel
    2
6
1 21:08 cache.properties.lock
-rw-r--r--
1 zouguangxian
wheel
19346
6
1 21:08 fileSnapshots.bin
-rw-r--r--
1 zouguangxian
wheel
19373
6
1 21:08 taskArtifacts.bin

By comparing the permissions of the file generatd by these commands, I found that gradle create files as :wheel group instead of :staff group.

The operation system is Mac OS Mountain Lion 10.8.3.

[zouguangxian@]$ uname -a
Darwin ZoutekiMacBook-Pro.local 12.3.0 Darwin Kernel Version 12.3.0: Sun Jan
6 22:37:10 PST 2013; root:xnu-2050.22.13~1/RELEASE_X86_64 x86_64

So looks that if gradle team change :wheel group to :staff group when the tool generate files will resolve this problem.


(Peter Niederwieser) #3

Which group files written by Gradle belong to isn’t controlled by Gradle, but by your OS/filesystem. Typically, the group is inherited from the parent directory.


(Zou Guangxian) #4
[zouguangxian@]$ ls -ls ~/Volumes/ | grep X
 0 drwxr-xr-x
2 zouguangxian
staff
   68
4
9 23:33 X
  [zouguangxian@]$ mount_smbfs -f 0664 -d 0775 //zouguangxian@host/x$ ~/Volumes/X
  [zouguangxian@]$ ls -ls ~/Volumes/ | grep X
32 drwxrwxr-x
1 zouguangxian
staff
16384 12 31
1979 X
  [zouguangxian@]$ groups zouguangxian
staff everyone _appstore localaccounts _appserverusr admin _appserveradm _lpadmin _lpoperator _developer access_bpf com.apple.access_screensharing-disabled

It looks like I’m not a member of wheel group and ‘wheel’ is not inherited from parent directory.

As http://en.wikipedia.org/wiki/Wheel_(Unix_term) described: > Modern Unix systems use user groups to control access privileges. The wheel group is a special user group used on some Unix systems to control access to the su command, which allows a user to masquerade as another user (usually the super user).


(Zou Guangxian) #5

Yes, the group is inherited from the parent directory.

If I set project-cache-dir to ~/tmp, the following command will succeed to execute.

[zouguangxian@]$ ls -la ~| grep tmp
drwxr-xr-x
  3 zouguangxian
staff
  102
6
1 23:35 tmp
[zouguangxian@]$ gradle --project-cache-dir ~/tmp tasks
[zouguangxian@]$ ls -la ~/tmp/1.6/taskArtifacts/
total 96
drwxr-xr-x
6 zouguangxian
staff
  204
6
1 23:35 .
drwxr-xr-x
3 zouguangxian
staff
  102
6
1 23:35 ..
-rw-r--r--
1 zouguangxian
staff
   30
6
1 23:35 cache.properties
-rw-r--r--
1 zouguangxian
staff
    2
6
1 23:35 cache.properties.lock
-rw-r--r--
1 zouguangxian
staff
19346
6
1 23:35 fileSnapshots.bin
-rw-r--r--
1 zouguangxian
staff
19373
6
1 23:35 taskArtifacts.bin

Is it a bug of mount_smbfs cause “java.io.IOException: Operation not supported” ?


(Mike Mitterer) #6

I am sure it’s not a Samba-bug. Reading and writing to all subdirectories works. In my case /Volumes/programming/DevJava/… is my DevVolume - all other projects are on that volume - never had a problem before with reading/writing files. I am using Java 6 - could this cause the problem? (I can’t switch to J7 at - the moment so I can’t test)


(Peter Niederwieser) #7

It may not be a Samba bug, but it’s likely Samba (setup) related. Also check execute rights (for listing directories) and try without Gradle daemon (’–no-daemon’). To Gradle/Java, it’s just another file system, hence I consider it unlikely that anything can or needs to be changed there. I’d be surprised if a different JRE helped, but it’s worth a shot.

I haven’t used Samba in a while, but I’d be hesitant to use it for builds, because disk performance tends to have a huge impact on build times.