-
Bug
-
Resolution: Unresolved
-
Major
-
None
The FSTrigger plugin but it doesn't seem to work with network folders (whether scanning files or folder).
FSTrigger Files Log gives me:
Polling on the master
The folder path '\\some_network_folder\to_scan' doesn't exist.
The computed file doesn't exist.
And FSTrigger Folder Log gives me:
Polling on the master
Trying to monitor the folder '\\some_network_folder\to_scan'
The directory '\\some_network_folder\to_scan' doesn't exist.
Using a network drive like Z:\ mapped to \\some_network_folder\to_scan, it doesn't work neither.
Also tried after doubling all backslashes, no luck.
[JENKINS-12354] Scanning a network folder such as \\some_network_folder\to_scan doesn't work
Have clearer instructions for reproduction. associated email thread http://goo.gl/HTFGi indicates Reporter found a workaround, but this may still be a bug in FSTrigger - FSTrigger is unable to traverse network shares with a specific Domain\Username & password.
To reproduce:
1. Have the Jenkins ( slave ) running as a windows service as "Local System Account"
2. put in a CIFS path for the FSTrigger directory value
3. FStrigger is unable to access the directory
The workaround is;
1. Have Jenkins running as a windows service with "This account" - an account with access rights to the network share
However, running in this fashion means that "headless" internet explorer testing from Jenkins will not work - it is necessary to have "Allow service to interact with desktop" for IE to run in a pseudo-headless fashion.
FStrigger should have the option to include Domain, Username and encrypted password, in the same manner as the "Publish over CIFS" plugin.
Dermot Canniffe
added a comment - - edited Have clearer instructions for reproduction. associated email thread http://goo.gl/HTFGi indicates Reporter found a workaround, but this may still be a bug in FSTrigger - FSTrigger is unable to traverse network shares with a specific Domain\Username & password.
To reproduce:
1. Have the Jenkins ( slave ) running as a windows service as "Local System Account"
2. put in a CIFS path for the FSTrigger directory value
3. FStrigger is unable to access the directory
The workaround is;
1. Have Jenkins running as a windows service with "This account" - an account with access rights to the network share
However, running in this fashion means that "headless" internet explorer testing from Jenkins will not work - it is necessary to have "Allow service to interact with desktop" for IE to run in a pseudo-headless fashion.
FStrigger should have the option to include Domain, Username and encrypted password, in the same manner as the "Publish over CIFS" plugin. Dermot Canniffe
added a comment - Further workaround:
Setting the Jenkins master to be "This account" - an account with access rights to the network share and the Slave to "Local System Account" with "Allow service to interact with desktop" set may allow headless browser testing, but may cause other problems with schizoid user rights.
Dermot Canniffe
added a comment - Further workaround:
Setting the Jenkins master to be "This account" - an account with access rights to the network share and the Slave to "Local System Account" with "Allow service to interact with desktop" set may allow headless browser testing, but may cause other problems with schizoid user rights. 
Jesse Docken
added a comment - Network shares belong to the user and not the system, so any mounted network shares (e.g., the Z:\ example above) will not work because they only get created when the user logs in. Using a plain UNC path will work itself so long as the share is configured to allow the computer's account to have access to it. If it's restricted to a user account, then you have to run the Jenkins slave service under that user account. The plugin could theoretically impersonate a user and attempt to access the file using Jenkins credentials management, but this is non-trivial to implement.
Jesse Docken
added a comment - Network shares belong to the user and not the system, so any mounted network shares (e.g., the Z:\ example above) will not work because they only get created when the user logs in. Using a plain UNC path will work itself so long as the share is configured to allow the computer's account to have access to it. If it's restricted to a user account, then you have to run the Jenkins slave service under that user account. The plugin could theoretically impersonate a user and attempt to access the file using Jenkins credentials management, but this is non-trivial to implement. I have the same problem. My job is bound to a windows slave which runs as LocalSystem (it is executing GUI tests and has to interact with the desktop). This slave / service does not have access to the network share. I would like to see something similar to the perforce plugin: it allows to restrict the polling to the master. My Jenkins master is running under a dedicated user and has access to the network share.
As a workaround I have defined a "trigger" job which does only the polling. This job starts the "worker" job when a file has changed.
Bernhard Berbuir
added a comment - - edited I have the same problem. My job is bound to a windows slave which runs as LocalSystem (it is executing GUI tests and has to interact with the desktop). This slave / service does not have access to the network share. I would like to see something similar to the perforce plugin: it allows to restrict the polling to the master. My Jenkins master is running under a dedicated user and has access to the network share.
As a workaround I have defined a "trigger" job which does only the polling. This job starts the "worker" job when a file has changed. 
I'm afraid I can't reproduce the problem.
I've just tested the last version on Windows with a UCN path and it's works very well.