Ошибка permission denied for relation

DEFAULT PRIVILEGES do not change permissions for existing objects. They are the default privileges for newly created objects and only for the particular role they belong to. If you do not specify the role when running ALTER DEFAULT PRIVILEGES, it defaults to the current role (when executing the ALTER DEFAULT PRIVILEGES statement.

Also, since you are using a serial column, which creates a SEQUENCE, you’ll want to set default privileges for sequences as well.

Run this on the user you create objects with, before you run the CREATE command:

ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON TABLES TO bspu;
ALTER DEFAULT PRIVILEGES [ FOR ROLE my_create_role] GRANT ALL ON SEQUENCES TO bspu;

A word of caution for pgAdmin users. There is a bug in all versions of pgAdmin III and pgAdmin4 (including v5.3). The reverse engineered SQL script for the database or schema nodes displays DEFAULT PRIVILEGES ignoring the owning user and is therefore incorrect in certain situations. I reported the bug (repeatedly), but the project encountered difficulties fixing it. pgAdmin III was discontinued in favor of pgAdmin4. The bug is still there in pgAdmin4.

For existing objects you may also be interested in this «batch» form of the GRANT command:

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO bspu;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA public TO bspu;

More under this related question on SO:

• Grant all on a specific schema in the db to a group role in PostgreSQL

Postgres databases can handle complex website functions easily.

But, what if you get a permission denied error for database Postgres, frustrating right?

This website error occurs due to the lack of database privileges like CONNECT, CREATE, etc.

At Bobcares, we often receive requests to fix the permission denied error as part of our Server Management Services.

Today, let’s discuss this error in detail and see how our Support Engineers fix it for our customers.

How to fix Permission denied for database Postgres?

Postgres is a powerful database that comes up with vast features to help developers.

But, it often shows up permission denied error. Finding the exact reason for this error can be quite tricky.

The core reason for the permission denied error in Postgres is the lack of several privileges.

Now, let’s see the main causes of this error and its respective fixes.

1. Missing CONNECT privilege

Recently, one of our customers approached us with a permission denied error in the Postgres. He tried to log in to his database using psql command,

psql userdb user --password

Here, userdb and user are the database name and username respectively.

But, after entering the password, he got the following error,

psql: FATAL: permission denied for database "userdb"
DETAIL: User does not have CONNECT privilege.

Our Support Engineers checked and found an error with CONNECT privilege.

Usually, the CONNECT privilege allows the user to connect to a database. And we check this privilege at the connection startup.

So, to grant CONNECT privilege, we followed the command,

GRANT CONNECT ON DATABASE userdb TO user ;

This resolved the error effectively.

2. Grant privileges to a new user

In some cases, users try to grant all privileges of a database to a new Postgres user other than the owner. For that, we use the command,

GRANT ALL PRIVILEGES ON DATABASE userdb TO new_user;

But, when we log in as the new user and try to read data from the table, it ends up showing the error,

ERROR: permission denied for relation table_name

This is because GRANT ALL PRIVILEGES ON DATABASE grants CREATE, CONNECT and TEMPORARY privileges on a database to a user.

But, none of these privileges permit the user to read data from the table.

Therefore, it requires the SELECT privilege. We resolve this permission denied error using the command.

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO new_user;

The new_user was then able to read data from the table.

Similarly, we can also resolve the permission denied error by setting DEFAULT privileges to the user.

Here, we use the ALTER DEFAULT PRIVILEGES command to define the default access privileges.

ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO new_user;

This will be specific to the schema specified in the command. Also, to apply it to the entire database, we use the command,

ALTER DEFAULT PRIVILEGES GRANT ALL ON TABLES TO new_user;

3. Missing Postgres user

In the control panel based servers, permission denied error can happen due to missing users as well. For instance, in control panels like Plesk, if the password for PostgreSQL user postgres does not correspond password in the Plesk database, it shows up errors.

Therefore, to fix it, we update the PostgreSQL user with the proper password and sync it with the Plesk DB. And confirm it from Plesk panel at:

[Stuck with permission denied error in Postgres?- We’ll help you.]

Conclusion

In short, the permission denied for database Postgres occurs due to the lack of certain privileges like CONNECT, CREATE, DEFAULT and so on. In today’s writeup, we discussed how our Support Engineers fix Postgres privileges for our customers.

var google_conversion_label = «owonCMyG5nEQ0aD71QM»;

5 ответов

CREATE USER readonly  WITH ENCRYPTED PASSWORD 'readonly';
GRANT USAGE ON SCHEMA public to readonly;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readonly;

-- repeat code below for each database:

GRANT CONNECT ON DATABASE foo to readonly;
c foo
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT ALL ON TABLES TO readonly; --- this grants privileges on new tables generated in new database "foo"
GRANT USAGE ON SCHEMA public to readonly; 
GRANT SELECT ON ALL SEQUENCES IN SCHEMA public TO readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readonly;

GRANT USAGE ON SCHEMA public to readonly;

GRANT ALL ON TABLE mytable TO myuser;

GRANT ALL ON TABLE tbm_grupo TO myuser;

postgres=# du
                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 flux      |                                                | {}
 postgres  | Superuser, Create role, Create DB, Replication | {}

postgres=# ALTER ROLE flux WITH Superuser;
ALTER ROLE
postgres=# du
                             List of roles
 Role name |                   Attributes                   | Member of 
-----------+------------------------------------------------+-----------
 flux      | Superuser                                      | {}
postgres  | Superuser, Create role, Create DB, Replication | {}

1. Предисловие

1.1 Обзор

Эта статья представляет несколько общих проблем PostgreSQL и начинается с явления, постепенно исследуя проблему, анализирует причину проблемы и дает решения.

Проблемы, описанные в этой статье, делятся на две категории: одна — проблема, которую PostgreSQL не может запустить, а другая — проблема, с которой некоторые объекты базы данных не могут быть доступны после запуска PostgreSQL.

1.2 Программная среда

Версия PostgreSQL, используемая в этой статье, составляет 9.2.

1.3 Некоторые согласованные сроки

Postgresql Путь установки: указывает путь установки платформы IVMS-8700 PostgreSQL, по умолчанию «D: Program Files Postgresql 9.6″ «» «»

Папка Bin: папка Bin под пути установки PostgreSQL.

Папка данных: папка данных в рамках пути установки PostgreSQL.

2. Вопросы и решения

2.1 PostgreSQL не может начать

Когда PostgreSQL не начался нормально, он снова потерпел неудачу в «Сервисе».

2.1.1 Портовая занятия

Сначала нам нужно определить, занят ли порт услуги. Порт по умолчанию службы PostgreSQL составляет 5432, поэтому мы выполняем следующие команды в командной строке

netstat -ano | find /i «5432»

Если найдено процесс использования порта 5432, это показывает, что занятие порта вызывает запуск услуги:

PID этого процесса — 2364. Вы хотите посмотреть, какой это процесс, вы можете выполнить:

  tasklist | findstr «2364»

Результаты выполнения следующие:

Вы можете положить конец этому процессу на странице Processcess-Process или по следующей команде:

taskkill /f /pid 5432

2.1.2 could not open control file “global/pg_control”：Permission denied

  Если порт не занят, то вы можете его использоватьPostgreSQLНативная команда запускает это.

ВойтиpostgresqlПод пути установки bin Папка, откройте командную строку здесь и выполните следующую команду:

.pg_ctl start -D ..data

Если программа сообщает о следующих ошибках：

ERROR: could not open control file “global/pg_control”: Permission denied

Он показывает, что текущие пользователи операционной системы теряют авторитет папки данных и ее контента.

Ниже приведено решение:

1. Во -первых, введите путь установки PostgreSQL, справа -щелкните папку данных, нажмите на атрибуты -Security -Editor, вы можете увидеть разрешения всех пользователей или групп пользователей.

2. Убедитесь, что система и администратор имеют «полное управление» разрешения. Пользовательская группа пользователей имеет только три типа разрешений: «чтение и выполнение», «Список содержимого папки» и «чтение». Когда база данных предлагает «недостаточные разрешения», следует добавлять «модификацию» и «написание».

3. Сохраните и попробуйте снова выступить под папкой бина:

.pg_ctl start -D ..data

Обратите внимание, может ли база данных PostgreSQL начать.

2.1.3 could not locate a valid checkpoint record

Если база данных активирована, ее предложено «запустить процесс сервера» и быть успешным в течение долгого времени. Как показано на рисунке ниже, вам необходимо проверить журнал запуска базы данных. Они расположены в PG_LOG в папке данных Анкет

Откройте журнал запуска базы данных, когда возникает проблема, и проверьте информацию.

Если в журнале есть информация, аналогичная следующим черным телам, это означает, что журнал до -записи (Wal (Wal, также известный как журнал транзакций) в базе данных PostgreSQL поврежден:

LOG:  could not open file «pg_xlog/0000000100000000000000E7» (log file 0, segment 231): No such file or directory

LOG:  invalid primary checkpoint record

LOG:  could not open file «pg_xlog/0000000100000000000000E7» (log file 0, segment 231): No such file or directory

LOG:  invalid secondary checkpoint record

PANIC:  could not locate a valid checkpoint record

Решение заключается в следующем:

Введите папку Bin, откройте командную строку здесь и выполните следующую команду:

.pg_resetxlog.exe -f ..data

После того, как журнал будет сброшен, попробуйте запустить базу данных.

2.1.4 Описание идентификатора события 0 из источника PostgreSQL не может быть найдено.

Если приведенный выше метод не решает проблему, то нам нужно ввести диспетчер событий, чтобы увидеть, есть ли какой -либо журнал ошибок:

В случае применения журнала зрителей визиторов, посмотрите, есть ли следующие ошибки:

Невозможно найти источник PostgreSQL мероприятие ID 0 описание. Не установлен на локальном компьютере, который вызвал этот инцидент,Или установка повреждена. Вы можете установить или восстановить компоненты на локальном компьютере.

Если такая информация появляется, это означает, что программное обеспечение PostgreSQL было повреждено и должно быть переустановлено. Тем не менее, файл данных не обязательно поврежден, поэтому, если в последний раз, когда он резервен, база данных сгенерировала очень важные данные (например, информация о счетах), вы должны скопировать папку данных в другой каталог, а затем переустановить платформу и и Восстановите данные папки данных.

2.1.5 Could not read from file «pg_clog/000E» at offset 172032

Есть также необычная ситуация. Если в журнале появляется следующая информация:

ERROR: could not access status of transaction 710708

DETAIL:  Could not read from file «pg_clog/000E» at offset 172032: No error.

Это находится вdataПод папкойpg_clogИмя 000E Файл журнала был потерян.

Решение заключается в следующем:

существуетlinux В операционной системе выполните следующие команды:

dd if=/dev/zero of=/root/000E bs=256k count=1

Или установите DD в Windows, а затем выполните:

dd if=/dev/zero of=D:00E bs=256k count=1

Затем скопируйте созданный файл 000e вdataПод папкойpg_clog середина.

2.2 После запуска базы данных некоторые базы данных или таблицы нельзя получить

В этом случае вам нужно войти dataПод папкойpg_logПапка, постоянно проверяйте беговые журналы.

2.2.1 permission denied for relation tb_door

Если в журнале есть аналогичная информация, это показывает, что у текущего пользователя доступа нет таблицыtb_doorНекоторые разрешения:

ERROR:  permission denied for relation tb_door

Если вы хотите текущего пользователя (чтобыmy_userНапример) наличие конкретных разрешений на доступ (на основеВыберите, вставьте, обновите, удаляйте в качестве примера), Вы можете решить это так:

1. Первый проходpostgresПользователь или владетьСоответствующие разрешения TB_DOOR, то есть журналы пользователя в базе данных, которая предоставила разрешения;
2. Выполнить следующие команды, чтобы предоставить разрешения пользователям:grant SELECT,INSERT,UPDATE,DELETE on tb_door to my_user

2.2.2 invalid page header in block 120 of relation base/272816/309624

Если в журнале появляется следующая информация:

ERROR: invalid page header in block 120 of relation base/272816/309624

Это означает, что файл таблицы данных поврежден. Обычно это вызвано ненормальным сбоем энергии или недоразумением.Здесь «272816» является идентификатором объекта (OID) базы данных проблемы.

Если количество поврежденных таблиц и количество поврежденных страниц невелико, мы можем восстановить целое за счет жертвоприношения части данных; если количество поврежденных таблиц слишком велика или потеря данных очень важна, мы Нужно восстановить данные из резервной копии.

Когда количество поврежденных таблиц и количество поврежденных страниц невелико, решение следующим образом:

1. Определите базу данных проблемы. Подключите любую базу данных и выполните оператор SQL ниже:

select datname from pg_database where oid = 272816;

Результаты запроса следующие:

testdb

Это означает, что название базы данных проблемы является TestDB

2. Найдите поврежденный объект базы данных. База данных задачи подключения выполните следующее оператор SQL:

select relname,relkind from pg_class where relfilenode = 309624

Если relkind = r в результатах запроса, таблица повреждена.

Например:

tb_door, r

Relname = tb_door Это означает, что поврежденная таблица — tb_door.

Если relkind = i в результатах запроса, это индекс, который поврежден.

Например:

dept_number_index, i

или же:

tb_dept_pkey, i

Следует отметить, что ущерб может быть обычным индексами или основным или уникальным ключом. Если имя индекса является «_pkey», оно, вероятно, будет принадлежать первичному ключу, и имя содержит «_key», оно может принадлежать к уникальному ключу.

Также необходимо обратить на это внимание. Предварительным условием для исправления таблицы/индекса является то, что поврежденная таблица — это таблица/индекс, созданная приложением, а не системная таблица PostgreSQL и индекс, созданный на нем. Если системная таблица/индекс, созданный на нем, повреждены, база данных необходимо восстановить из резервной копии. Чтобы определить, является ли таблица системной таблицей, самый простой способ: если имя таблицы «pg_», это означает, что это системная таблица.

3. Исправьте поврежденный объект базы данных. Поврежденная база данных происходит для выполнения команды ремонта.

Если таблица повреждена, возьмите TB_DOOR в качестве примера, затем выполните следующие команды, чтобы завершить ремонт:

set zero_damaged_pages = on;

vacuum full tb_door;

reindex table tb_door;

Если поврежденный является обычным индексом, возьмите dept_number_index в качестве примера, затем выполните его по порядку:

set zero_damaged_pages = on;

reindex index dept_number_index;

Если урон является основным ключом или уникальным ключом, сначала вам нужно найти таблицу, которую он находится. TB_DEPT_PKEY В качестве примера:

Select tablename,indexname from pg_indexes where indexname = ‘tb_dept_pkey’;

результат поиска:

tb_dept, tb_dept_pkey

Затем получите определение индекса:

select pg_get_constraintdef((select oid from pg_constraint where conname = ‘ tb_dept_pkey ‘));

результат поиска:

       PRIMARY KEY (dept_id)

Затем повторно измените это ограничение:

Alter table drop constriant tb_dept_pkey;

Alter table add constraint tb_dept_pkey PRIMARY KEY (dept_id);

2.2.3 could not read block 190 in file «base/272816/309624»

Решение и метод этой проблемы2.2.2 Проблема фестиваля точно такая же.

2.2.4 could not open file «base/272816/379923»: No such file or directory

Если в журнале появляется следующая информация:

2019-01-21 14:28:03 HKT ERROR:  could not open file «base/272816/379923″: No such file or directory

Объяснять,oidза272816В базе данных,oidза379923Файл, соответствующий таблице, удален.

Решение заключается в следующем:

1. Сначала судите, какая база данных произошла. Подключите любую базу данных и выполните следующим образомsql：

select datname from pg_database where oid = 272816

Результаты запроса следующие:

    testdb

2. Восстановите базу данных из резервной копии.