After Installation Problem

ERPNext
1

Installed on Ubuntu LiveServer 20.04.1 HyperV Instance.

Installation is successful, using this tutorial How To Install an ERPNext Stack on Ubuntu 20.04 | DigitalOcean

On initial login, using the Administrator user and predefined password the UI returns “Verified” followed immediately by the following message;

Not Permitted and the system refuses access to the Desk interface

I have reproduced this issue several times from a new VM forward. What is the issue that is stopping access to the Desk interface after successful validation of the predefined Administrator user login?

From the command line at the server, bench version returns
erpnext 12.10.1
frappe 12.8.4

The DB instance is MariaDB 10.5

2

From frappe-bench folder try: bench mariadb and see if you can login with same credentials.

3

Connection id: 49
Current database: _d83a21695fdae043
Current user: _d83a21695fdae043@localhost
SSL: Not in use
Current pager: less -SFX
Using outfile: ‘’
Using delimiter: ;
Server: MariaDB
Server version: 10.3.22-MariaDB-1ubuntu1-log Ubuntu 20.04
Protocol version: 10
Connection: Localhost via UNIX socket
Server characterset: utf8mb4
Db characterset: utf8mb4
Client characterset: utf8mb4
Conn. characterset: utf8mb4
UNIX socket: /var/run/mysqld/mysqld.sock
Uptime: 10 min 59 sec

Threads: 9 Questions: 142 Slow queries: 0 Opens: 41 Flush tables: 1 Open tables: 35 Queries per second avg: 0.215

Note that you are running in safe_update_mode:
UPDATEs and DELETEs that don’t use a key in the WHERE clause are not allowed.
(One can force an UPDATE/DELETE by adding LIMIT # at the end of the command.)
SELECT has an automatic ‘LIMIT 1000’ if LIMIT is not used.
Max number of examined row combination in a join is set to: 1000000

MariaDB [_d83a21695fdae043]>

And that is the problem.

4

Have you checked the nginx/mysql log files?

5

Which specific log files and located where?
This is a failed permissions thing from what I can tell. As soon as the login takes place successfully, permission to access the desk mode is denied.

6

Is the bar across the top visible with E , search box , Settings, Help ?

7

The issue is this,

After installing multiple times on Ubuntu 20.04.1 LTS vm’s using the process defined in the Digital Ocean Blog How To Install an ERPNext Stack on Ubuntu 20.04 | DigitalOcean

I get a fully functional VM but after the login of the Administrator completes and Verifies it immediately refuses access to the Desk interface, and any possibility to configure is lost.

What is the problem and how can I fix it?

8

i also faced same and tried below step to achiev and working fine now.

  1. bench clear-cache
  2. bench clear-website-cache

If still persist same then go incognito mode and config all.

clear all browse cache and history.

1 Like
9

Thanks! Problem solved.

How did you come to this solution? Over the last four weeks I built this application at least six times from scratch, and the issue appeared in all but one build attempt.

Do you know what the cause of the cache issue is? On multiple occasions I cleared the browser cache without success, but the issue appears to be in the redis cache.

admin@erpnext:~/frappe-bench$ bench clear-cache
admin@erpnext:~/frappe-bench$ bench clear-website-cache
admin@erpnext:~/frappe-bench$ bench start
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
/usr/lib/python3.8/subprocess.py:844: RuntimeWarning: line buffering (buffering=1) isn’t supported in binary mode, the default buffer size will be used
self.stdout = io.open(c2pread, ‘rb’, bufsize)
10:39:53 system | redis_cache.1 started (pid=4583)
10:39:53 redis_cache.1 | 4590:C 16 Aug 2020 10:39:53.195 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
10:39:53 redis_cache.1 | 4590:C 16 Aug 2020 10:39:53.195 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=4590, just started
10:39:53 redis_cache.1 | 4590:C 16 Aug 2020 10:39:53.195 # Configuration loaded
10:39:53 redis_cache.1 | 4590:M 16 Aug 2020 10:39:53.195 * Increased maximum number of open files to 10032 (it was originally set to 1024).10:39:53 redis_cache.1 | 4590:M 16 Aug 2020 10:39:53.195 # Could not create server TCP listening socket 127.0.0.1:13000: bind: Address already in use
10:39:53 system | redis_cache.1 stopped (rc=1)
10:39:53 system | redis_socketio.1 started (pid=4588)
10:39:53 redis_socketio.1 | 4592:C 16 Aug 2020 10:39:53.200 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
10:39:53 redis_socketio.1 | 4592:C 16 Aug 2020 10:39:53.200 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=4592, just started
10:39:53 redis_socketio.1 | 4592:C 16 Aug 2020 10:39:53.200 # Configuration loaded
10:39:53 redis_socketio.1 | 4592:M 16 Aug 2020 10:39:53.200 * Increased maximum number of open files to 10032 (it was originally set to 1024).10:39:53 redis_socketio.1 | 4592:M 16 Aug 2020 10:39:53.200 # Could not create server TCP listening socket 127.0.0.1:12000: bind: Address already in use
10:39:53 system | redis_socketio.1 stopped (rc=1)
10:39:53 system | watch.1 started (pid=4596)
10:39:53 system | worker_long.1 started (pid=4599)
10:39:53 system | redis_queue.1 started (pid=4602)
10:39:53 redis_queue.1 | 4604:C 16 Aug 2020 10:39:53.216 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
10:39:53 redis_queue.1 | 4604:C 16 Aug 2020 10:39:53.216 # Redis version=5.0.7, bits=64, commit=00000000, modified=0, pid=4604, just started
10:39:53 redis_queue.1 | 4604:C 16 Aug 2020 10:39:53.216 # Configuration loaded
10:39:53 redis_queue.1 | 4604:M 16 Aug 2020 10:39:53.217 * Increased maximum number of open files to 10032 (it was originally set to 1024).10:39:53 redis_queue.1 | 4604:M 16 Aug 2020 10:39:53.217 # Could not create server TCP listening socket 127.0.0.1:11000: bind: Address already in use
10:39:53 system | redis_queue.1 stopped (rc=1)
10:39:53 system | worker_default.1 started (pid=4598)
10:39:53 system | socketio.1 started (pid=4597)
10:39:53 system | worker_short.1 started (pid=4600)
10:39:53 system | schedule.1 started (pid=4594)
10:39:53 system | web.1 started (pid=4595)
10:39:53 system | sending SIGTERM to web.1 (pid 4595)
10:39:53 system | sending SIGTERM to socketio.1 (pid 4597)
10:39:53 system | sending SIGTERM to watch.1 (pid 4596)
10:39:53 system | sending SIGTERM to schedule.1 (pid 4594)
10:39:53 system | sending SIGTERM to worker_short.1 (pid 4600)
10:39:53 system | sending SIGTERM to worker_long.1 (pid 4599)
10:39:53 system | sending SIGTERM to worker_default.1 (pid 4598)
10:39:53 system | worker_default.1 stopped (rc=-15)
10:39:53 system | web.1 stopped (rc=-15)
10:39:53 system | schedule.1 stopped (rc=-15)
10:39:53 system | worker_short.1 stopped (rc=-15)
10:39:53 system | watch.1 stopped (rc=-15)
10:39:53 system | socketio.1 stopped (rc=-15)
10:39:53 system | worker_long.1 stopped (rc=-15)

10

One last observation on this issue,

I am using a Win10 Pro Workstation on an 8 core Intel machine with 64GB of ram and running HyperV VM’s built on Ubuntu 20.04.1 LTS Live Server iso’s. This is a development environment only. I expect to be building production instances using a KVM based server system. Is this problem a known issue on all Linux platforms, or an issue related to choice of platform components?

It seems occur on startup of a VM and then can be cleared.

11

It hasn’t been widely reported here, so probably the latter. Ubuntu 20 being a new kid on the block may have more to do with it than other factors.

12

I first reported this as an installation problem, but it occurs in other circumstances as well.

My question for the user community is, Does this occur to other users in differing operating environments.

Mine is;
Ubuntu 201.04.1 LTS Server on Hyper-V Host
ERPNext: v12.10.1 (version-12)
Frappe Framework: v12.8.4 (version-12)

Client is Chrome Version 84.0.4147.125
On Windows 10 Pro

On system startup and first client access, both the server cache and client browser cache may need to be cleared to allow login at the /desk level

Once cleared the system is functional until either a server restart, OR an attempt is made to access a card for which there is no permission granted. This attempt can then force the cache clearance to be carried out again.

My question is:

Is this related only to the Ubuntu 20 Linux system or is it seen on other OS circumstances ?