Error message when exiting pgadmin3

[rouault]

When exiting pgadmin3, I get the following 2 popups :

"can't remove file '/home/user/.pgadmin3' (error 1: Opération non permise)"

and then

"Failed to update user configuration file."

[hamish]

5.0rc5 mini ISO: file is editible by the user. but if you try to 'rm ~/.pgadmin3' on the command line you get the same error message.

it seems hardlinked to another copy on the disc at /usr/local/share/gisvm/app-conf/postgis/pgadmin3 ??

solution: edit ~/.pgadmin3 on the master VM before build_iso.sh so they are different. we can probably adjust one of the window placement config options Height=524 -> Height=525 without much harm.

Hamish

[darkblueb]

not fixed in RC6

[johanvdw]

Is fslint hardlinking also run on files in /home?

[hamish]

Replying to johanvdw:

Is fslint hardlinking also run on files in /home?

good point, no it is not. just /usr /opt /lib (although some things in /home are symlinks to those places)

I wonder what could cause the file system error to a regular file in /home then? It is as if the user does not own their own uid.gid file.

Paul Campbell wrote:

One or more of the file's or directory's attribute bits are set incorrectly.
If the I bit is set, for example, you won't be able to change file permissions
with chmod.

The solution is to use lsattr to display file and directory attributes, and
chattr to set and unset them.

​http://stason.org/TULARC/os/linux-faq/157-Operation-not-permitted.html

Hamish

[wildintellect]

I wonder if this is another VM vs ISO difference. Remember the weirdness around the user User not be being the same as the User account on the ISO, possibly even having a different user number. I think it's because the account doesn't exist until the livedvd is actually booted or something like that. Could that be the cause? I don't recall this bug being in previous releases though and pgadmin3 is something I normally test (maybe I've always used the vm). Can someone check a previous release iso?

[hamish]

hmm, on the iso are there two entries for "user" in /etc/passwd or /etc/group ? ?!

uid.gid as seen by ls should always follow those.

I wonder if the lack-of-background-image problem you (Alex) saw on your burned dvd could be a manifestation of the same root problem?

H

[hamish]

re. wrong uid.gid theory, what does ls -an say?

H

[hamish]

and how about lsattr -a ?

[hamish]

5.0rc6 full ISO:

• there is just one "user" in /etc/passwd and /etc/group

• ls -la and 'ls -na' show a few files still owned by root (ahem), but nothing unusual about ~/.pgadmin3, it's owned by user.user aka 1000.1000.

• I notice I can't move desktop icons to the trash, or into a newly created "Demos" directory. Same "Operation not permitted" error for files like password.txt, but also I get a Invalid cross-device link error message when I try to move/delete the directories.

• lsaatr -a shows errors for all the files:

...
Inappropriate ioctl for device While reading flags on ./.pgadmin3
...

also lsattr doesn't like symlinks, but I think that's normal behaviour.

so are files in /home on another (virtual) partition on the ISO as /usr, but not fslints compressed /usr??? it sounds like an error if the hardlink file is not on the same partition as its twin, but all seem to be on the same 'aufs' partition when I poke around. or maybe fslint has nothing to do with it at all.

Invalid cross-device link: I assume nothing physically in home is symlinked outside to the FS, only vice versa.

Inappropriate ioctl for device I assume this is because /home (or files owned by 'user'?) are held in a RAM fs not a ext[2-4] fs as lsattr demands. (in fact there are no ext fs's on the booted ISO). Would have to do some research about aufs et al.

I can create and rm a file in the home dir without problems, so the disc should be usable, just immutable. After sudo suing to root, I can rm files without errors. /usr/ossim is installed as "user" (ahem), but I'm not permitted to remove files from there.

probably we should actively pursue this bug, and probably the place to do that is the remastersys mailing lists.

Hamish

[johanvdw]

I don't think fslint has anything to do with this. Wouldn't it simply be that the files on the iso (which are read only) and in the home directory are not actually copied to the ramdrive but just get a symlink there. It makes sense in many cases (eg datasets). This also explains why there are no issues on the virtual machine.

[kalxas]

This seems to be fixed in rev8192. Exiting from pgadmin3 while booting from iso does not give any error messages.