Maven Clean Fails on Linux Vagrant Shared Drive

[Kevin Meredith]

[please note that I posted this question in StackOverflow too - http://stackoverflow.com/questions/23089023/maven-clean-fails-on-linux-vagrant-shared-drive]

Using vagrant, I git clone'd my java app to c:/shared. In my Vagrantfile, I specified that my host's c:/shared will be mapped to /home/vagrant/myapp on my Virtual Machine.

When I run mvn clean compile from within the VM, I ran into this error:

core/myapp/target/classes/com/myapp/...
        at org.apache.maven.plugin.clean.CleanMojo.execute(CleanMojo.java:215)
        at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
        at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
        ... 19 more
Caused by: java.io.IOException: Failed to delete core/myapp/target/classes/com/myapp/...
        at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:249)
        at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:191)
        at org.apache.maven.plugin.clean.Cleaner.delete(Cleaner.java:158)

However, the Maven build succeeds on my Windows (host) machine.

Running ls gives an odd output as the privileges show up as question marks(?):

[vagrant-centos65 parent]$ ls -lrot target/...
ls: cannot access ...
?????????? ? ? ?            ? $Class$$doMethod$1$1$$anonfun$apply$2.class

I'm running as user kevin, where as /home/vagrant/myapp is owned by vagrant. However, most, if not all, of myapp's directories have wide open (766 or 777) rights.

In the past, I've successfully compiled on the guest VM in a directory shared between host and guest.

I'm using:

vagrant - 1.3.5
Maven - 3.2.1
VirtualBox - 4.3.8

Also, I observed that this particular folder (C:) is not being indexed per this post.

Why would the build succeed on the host, but not the guest?

[Alvaro Miranda Aguilera]

Hello,

The way the shared folder is implemented,is not a real filesystem, so some languages have problems with the code in there. I know python fail on some operations, so maybe your is hitting that.

The first troubleshooting you can do is a root user copy the whole folder

rsync -PavzHl /source /test

and try in test.. as root the permissions will remain the same and with those parameters links will be copied as links, etc.

If that works, blame virtualbox shared folder, and try to use vagrant to rsync the files to the vm.

If the copy also fails, then the issue is not on the filesystem, try to do  chown -R kevin: /test and try, if that work, then is permissions.. on Vagrantfile you can setup owner and permissions of the shared folder.

Give a try let's see where it fails/work..

Alvaro.

[Kevin Meredith]

Running your `rsync ...` command without sudo, I then successfully compiled my code.

Once I finished the above, I saw that you mentioned "root user copy the whole folder," I figured I should re-run the `rsync ...` but with "sudo" in front of the command.

However, doing an ls -lrot on my VM shows that my /u01/build/share directory is owned by "kevin". That's a result of the following change that I added to my Vagrantfile:

config.vm.synced_folder "c:/dev/share", "/u01/build/share", type: "rsync", owner: "kevin"

When I tried to re-build on /u01/build/share/my_webapp with `mvn clean`, I still got an IO.Exception on a single file with the odd question marks (?) in the permissions section of the ls output.

I'm using Windows for my host, so NFS isn't possible.

Any other ideas? I appreciate your suggestions, Alvaro.

[Alvaro Miranda Aguilera]

so, if the rsync without without the sudo worked, then the user you used is the oneyou need to setup in the shared folder

do

ls -al /sharedfolder

ls -al /copyrsyncwithoutsudo

ls -al /copyrsyncwithsudo

to check the different permissions.

be clar to highligh the ones what work ( i got copy rsync without sudo)

--
You received this message because you are subscribed to the Google Groups "Vagrant" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vagrant-up+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kevin Meredith]

The problem turned out to be a Scala CLASS file of length 161 characters. My path + 161 = ~260 characters

Running `mvn clean` on a Linux VM from a shared directory on Windows, I limited the length of the Scala CLASS names using the scalac option: "-Xmax-classfile-name"

Full credit goes to monkjack - http://stackoverflow.com/a/23138361/409976