In 9.2.1.8 I had some rsync tasks (in Module mode) that pulled data from a Linux machine, but after updating to 9.3 I destroyed the pool to which these tasks pointed and expanded another pool. Now I can neither edit the rsync tasks to change the destination path nor can I create new tasks that point to the correct path: in both cases I click OK, there is no error message, but the updated or new task is not saved.
-
Important Announcement for the TrueNAS Community.
The TrueNAS Community has now been moved. This forum has become READ-ONLY for historical purposes. Please feel free to join us on the new TrueNAS Community Forums
9.3: Can't edit Rsync task or create new one
- Thread starter Z300M
- Start date
- Status
Bug report filed: #7259
David K[something or other -- Sorry, David] posted to my bug report #7259 (which has now been marked as a duplicate of a later report!) that checking the "Rsync Create" box enables Rsync tasks to be created and edited, and I can confirm that that works for me too.
No, that's also marked as a Duplicate -- of #7304.
I haven't tried creating any new tasks since that update, but I have been able to edit old ones.
- Joined
- Mar 18, 2014
- Messages
- 1,177
Just to add my tuppence-worth :
There is no fix for me in the latest SU.
I reverted to the original 9.3-release and it works fine, so it was broken in mid December.
There are five bugs open; most of which are classified as duplicates of each other :
7304
7259
7535
7534
7351
except for 7304 and that does not appear in the "SU Candidate" custom query.
I think it has fallen off the radar!!!
There is no fix for me in the latest SU.
I reverted to the original 9.3-release and it works fine, so it was broken in mid December.
There are five bugs open; most of which are classified as duplicates of each other :
7304
7259
7535
7534
7351
except for 7304 and that does not appear in the "SU Candidate" custom query.
I think it has fallen off the radar!!!
The most recent update I applied included one for an Rsync problem, but I don't recall the Bug#. Even before that fix (as I posted previously), I was able to create and edit Rsync tasks if I checked the "Rsync Create" box. That box now has a new name (which I do not recall), and I no longer need to check it.
- Joined
- Mar 18, 2014
- Messages
- 1,177
"Rsync Create" became "Validate Remote Path" in FreeNAS-9.3-STABLE-201501162230.
I find that the logic has been reversed in that prior to FreeNAS-9.3-STABLE-201501162230 I need to check the box to be able to save an edited Rsync task; after the SU, "Validate Remote Path" is set and I need to clear it to save successfully.
It should not be necessary to set or reset this option in order for the save to complete.
Create and edit are still broken.
Bug #7594
I find that the logic has been reversed in that prior to FreeNAS-9.3-STABLE-201501162230 I need to check the box to be able to save an edited Rsync task; after the SU, "Validate Remote Path" is set and I need to clear it to save successfully.
It should not be necessary to set or reset this option in order for the save to complete.
Create and edit are still broken.
Bug #7594
adrianwi
Guru
- Joined
- Oct 15, 2013
- Messages
- 1,231
Yes, I've been able to amend and save rsync tasks in the latest update - 201501301837 - but only if the Validate Remote Path checkbox is unchecked. If this is checked, it won't let me save.
Perhaps this is how it's been designed to work?
I am getting this appearing in the console though:
Perhaps this is how it's been designed to work?
I am getting this appearing in the console though:
Code:
Feb 1 22:12:04 freenas2 notifier: Traceback (most recent call last): Feb 1 22:12:04 freenas2 notifier: File "/usr/local/www/freenasUI/middleware/notifier.py", line 5734, in <module> Feb 1 22:12:04 freenas2 notifier: print f(*sys.argv[2:]) Feb 1 22:12:04 freenas2 notifier: File "/usr/local/www/freenasUI/middleware/notifier.py", line 5165, in rsync_command Feb 1 22:12:04 freenas2 notifier: return rsync.commandline() Feb 1 22:12:04 freenas2 notifier: File "/usr/local/www/freenasUI/tasks/models.py", line 507, in commandline Feb 1 22:12:04 freenas2 notifier: if rsync_delayupdates: Feb 1 22:12:04 freenas2 notifier: NameError: global name 'rsync_delayupdates' is not defined
- Joined
- Mar 18, 2014
- Messages
- 1,177
The developer has clarified what he is trying to do in #7594:
https://bugs.freenas.org/issues/7594
The path validation does not work for my config and it looks like it is broken for you too.
rgds
https://bugs.freenas.org/issues/7594
The path validation does not work for my config and it looks like it is broken for you too.
rgds
I cannot create new rsync or execute old one since update to FreeNAS-9.3-STABLE-201501301837
Getting this stuff whatever I try to do with rsync tasks from GUI:
This is quite annoying...
Getting this stuff whatever I try to do with rsync tasks from GUI:
Code:
Feb 2 01:40:33 AtomicStorage notifier: Traceback (most recent call last): Feb 2 01:40:33 AtomicStorage notifier: File "/usr/local/www/freenasUI/middleware/notifier.py", line 5734, in <module> Feb 2 01:40:33 AtomicStorage notifier: print f(*sys.argv[2:]) Feb 2 01:40:33 AtomicStorage notifier: File "/usr/local/www/freenasUI/middleware/notifier.py", line 5165, in rsync_command Feb 2 01:40:33 AtomicStorage notifier: return rsync.commandline() Feb 2 01:40:33 AtomicStorage notifier: File "/usr/local/www/freenasUI/tasks/models.py", line 507, in commandline Feb 2 01:40:33 AtomicStorage notifier: if rsync_delayupdates: Feb 2 01:40:33 AtomicStorage notifier: NameError: global name 'rsync_delayupdates' is not defined
This is quite annoying...
I see that the status of Bug report #7594 is "waiting for feedback" -- but from whom?
Seeing the same here.
adrianwi
Guru
- Joined
- Oct 15, 2013
- Messages
- 1,231
Edited rsync tasks scheduled for last night didn't run, and when I try to run manually I get this:
Code:
Request Method: POST Request URL: http://192.168.168.165/tasks/rsync/10/run/ Software Version: FreeNAS-9.3-STABLE-201501301837 Exception Type: NameError Exception Value: global name 'rsync_delayupdates' is not defined Exception Location: /usr/local/www/freenasUI/../freenasUI/tasks/models.py in commandline, line 507 Server time: Mon, 2 Feb 2015 06:32:41 +0000 Traceback Request information GET No GET data POST Variable Value __form_id u'form_str' FILES No FILES data COOKIES Variable Value sessionid 'hcrevqb4xkofa6b3z504vv04dh2v1o71' csrftoken '4ulkDS8jscyZqvT1QQuuIrRoadFOhxUt' fntreeSaveStateCookie 'root%2Croot%2F35%2Croot%2F50%2Croot%2F50%2F57%2Croot%2F50%2F57%2F58%2Croot%2F1%2F5%2Croot%2F74%2Croot%2F74%2F75%2Croot%2F52%2F59%2Croot%2F79%2F80%2Croot%2F91%2F124%2F126%2Croot%2F99%2F132%2Croot%2F99%2F132%2F134%2Croot%2F54%2F61%2F62%2Croot%2F54%2F61%2F62%2F71%2Croot%2F99%2Croot%2F54%2Croot%2F54%2F61%2Croot%2F54%2F61%2F62%2F67%2Croot%2F100%2F133%2Croot%2F100%2F133%2F135%2Croot%2F89%2F90%2Croot%2F55%2F62%2Croot%2F100%2Croot%2F55%2F62%2F63%2F72%2Croot%2F56%2F63%2Croot%2F56%2F63%2F64%2Croot%2F57%2F64%2Croot%2F91%2F92%2Croot%2F57%2Croot%2F57%2F64%2F65%2Croot%2F55%2Croot%2F55%2F62%2F63%2Croot%2F10%2F23%2Croot%2F58%2F65%2Croot%2F58%2F65%2F66%2Croot%2F23%2Croot%2F23%2F30%2Croot%2F60%2F61%2Croot%2F92%2Croot%2F92%2F93%2Croot%2F126%2Croot%2F167%2Croot%2F60%2F61%2F62%2Croot%2F97%2Croot%2F97%2F98%2Croot%2F57%2F58%2Croot%2F57%2F58%2F59' META Variable Value HTTP_X_REQUESTED_WITH 'XMLHttpRequest' HTTP_ORIGIN 'http://192.168.168.165' wsgi.url_scheme 'http' PATH_INFO u'/tasks/rsync/10/run/' REMOTE_ADDR '192.168.168.50' CONTENT_LENGTH '18' wsgi.multiprocess False SERVER_SOFTWARE 'nginx/1.6.2' DOCUMENT_ROOT '/usr/local/etc/nginx/html' HTTP_COOKIE 'csrftoken=4ulkDS8jscyZqvT1QQuuIrRoadFOhxUt; fntreeSaveStateCookie=root%2Croot%2F35%2Croot%2F50%2Croot%2F50%2F57%2Croot%2F50%2F57%2F58%2Croot%2F1%2F5%2Croot%2F74%2Croot%2F74%2F75%2Croot%2F52%2F59%2Croot%2F79%2F80%2Croot%2F91%2F124%2F126%2Croot%2F99%2F132%2Croot%2F99%2F132%2F134%2Croot%2F54%2F61%2F62%2Croot%2F54%2F61%2F62%2F71%2Croot%2F99%2Croot%2F54%2Croot%2F54%2F61%2Croot%2F54%2F61%2F62%2F67%2Croot%2F100%2F133%2Croot%2F100%2F133%2F135%2Croot%2F89%2F90%2Croot%2F55%2F62%2Croot%2F100%2Croot%2F55%2F62%2F63%2F72%2Croot%2F56%2F63%2Croot%2F56%2F63%2F64%2Croot%2F57%2F64%2Croot%2F91%2F92%2Croot%2F57%2Croot%2F57%2F64%2F65%2Croot%2F55%2Croot%2F55%2F62%2F63%2Croot%2F10%2F23%2Croot%2F58%2F65%2Croot%2F58%2F65%2F66%2Croot%2F23%2Croot%2F23%2F30%2Croot%2F60%2F61%2Croot%2F92%2Croot%2F92%2F93%2Croot%2F126%2Croot%2F167%2Croot%2F60%2F61%2F62%2Croot%2F97%2Croot%2F97%2F98%2Croot%2F57%2F58%2Croot%2F57%2F58%2F59; sessionid=hcrevqb4xkofa6b3z504vv04dh2v1o71' HTTP_HOST '192.168.168.165' HTTP_ACCEPT_LANGUAGE 'en-us' HTTPS '' REQUEST_URI '/tasks/rsync/10/run/' HTTP_REFERER 'http://192.168.168.165/' SERVER_NAME 'localhost' CSRF_COOKIE u'4ulkDS8jscyZqvT1QQuuIrRoadFOhxUt' REDIRECT_STATUS '200' HTTP_CONTENT_LENGTH '18' DOCUMENT_URI '/tasks/rsync/10/run/' SCRIPT_NAME u'' HTTP_CONTENT_TYPE 'application/x-www-form-urlencoded' CONTENT_TYPE 'application/x-www-form-urlencoded' HTTP_X_CSRFTOKEN '4ulkDS8jscyZqvT1QQuuIrRoadFOhxUt' HTTP_USER_AGENT 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_2) AppleWebKit/600.3.18 (KHTML, like Gecko) Version/8.0.3 Safari/600.3.18' HTTP_ACCEPT '*/*' wsgi.errors <flup.server.fcgi_base.TeeOutputStream object at 0x812803350> SERVER_PROTOCOL 'HTTP/1.1' wsgi.multithread True HTTP_CONNECTION 'keep-alive' SERVER_ADDR '192.168.168.165' REQUEST_METHOD 'POST' GATEWAY_INTERFACE 'CGI/1.1' HTTP_ACCEPT_ENCODING 'gzip, deflate' SERVER_PORT '80' QUERY_STRING '' wsgi.input <flup.server.fcgi_base.InputStream object at 0x812807310> REMOTE_PORT '56879' wsgi.run_once False wsgi.version (1, 0)
- Status
