DirectAdmin 1.679

Active8 said:
What I recall is if the OS outdated you cant update to the latest DA version, something i thought to because you were stucked to 1.668, we are now on 1.679.

EDIT
Ah found it : In case if your OS is based on RHEL 7 (CentOS 7.X or CloudLinux 7.X one), the latest DA version that is supported there is 1.668

More info here regarding manual update with CLI here
Click to expand...
Thank you. I have passed your message/advice to the hosting support.
 
I have an issue i really don't understand, and started since 1.679:

In the filemanager:
if i extract an ZIP archive from within the filemanager, permissions of the extracted are 777 (dirs) en 666 (files).
where are these 777 and 666 coming from?

within the filemanager creating a map manual get 755, creating a file gets 644.
uploading IN the filemanager also 755 and 644

ftp'ing from external also gets 755 and 644
unpacking / extracting a tar.gz does exactly what it should if permissions are set inside.

why does extracted data from a zip in the filemanager get 777 and 666?
 
zEitEr said:
Do you have the same issue when you unpack the ZIP archive in CLI (using SSH as a regular user, not root)?
Click to expand...

And there i never thought of....
That was a good question!

running 'unzip' in a CLI session indeed results in exactly same permissions.

did a 'unzip -Z' also, and that shows these rights are in that archive.

hmm..
 
did a test from 3 different Windows machines (2 different locations), and used default zip program from Microsoft, 7-Zip, and a classic WinZip.
all 3 archives arrive with 'unzip -Z' saying 666 and 777.
 
further tests:
all default created zips oridinally created on Windows will get 666 and 777 regardless umask of user.
zips without rights and attributes set on files and dirs will get the user rights (when logged in as user) or 666 and 777 when logged in as root or reseller or admin acting as that user (also unwanted ofcourse).

am i very annoying as i say that as this point i really miss the fm_file_permissions and fm_dir_permissons settings? (for both zips in general, and as admin acting for other users)?
 
Exactly the same issue here. Any time we unzip a .zip file using the File Manager, it assigns 666 permissions to files and 777 to folders.

On top of that, we also noticed that dragging and dropping files into other folders no longer works (even in version 1680). Now we have to click the "Move" button to do this. It used to be much more convenient before.

I couldn’t find anything in the documentation mentioning these changes to file permissions or drag-and-drop behavior.
 
paulonichio said:
Exactly the same issue here.

I couldn’t find anything in the documentation mentioning these changes to file permissions or drag-and-drop behavior.
Click to expand...

There are some references about file permissions and umask.
I think the outcome we experience is a result of this in the documentation (Release version changelog):

Version: 1.679
https://docs.directadmin.com/change...l#faster-and-more-secure-file-manager-actions
Key improvements:
- The archive extract action will not use tar or unzip CLI tools. All archive processing logic is built-in.
Click to expand...

and:

https://docs.directadmin.com/change...use-umask-for-default-filemanager-permissions:
"Default permissions for newly uploaded files and created directories using filemanager now rely on umask set for [email protected].
This deprecates fm_file_permissions and fm_dir_permissons fields in directadmin.conf"
Click to expand...

the above is documentation about this.
let me explain with an example:

the first part is not the real issue, but this is why Alex G. asked me about the CLI unzip (probably to see if there are differences between the 'filemanager newly inbuild ZIP / decompress functionality, and the 'old' style using default Unix 'unzip').

the second part, 'using umask' for default permissions, is where it starts with our issues.
as a result of the newly filemanager the 'fm_xxxx' style is deprecated and removed. (see changelog)

but.... zip files DO have permissions, not Unix style, but comparable with 666 and 777, on a lot of OS's. On Windows starting from at least Windows 7 (didt want to make the effort to find an WIndows XP or old windows 2000 server)

what happened in the past, Directadmin 1.678 and before, with a Windows created ZIP:
1. extract files and dirs in filemanager: permissions are set according to 'FM_xxxx' settings (regardless 'admin' or 'user').
2. extract files and dirs in CLI session: permissions are set according to rights in ZIP, getting 666 and 777 as these permissions are IN that ZIP.

what happens now in Directadmin since 1.679:
1. extract files and dirs in filemanager: permissions are set according to the zip, so 666 and 777, same as CLI.
2. extract files and dirs in CLI session: permissions are set according to rights in ZIP, getting 666 and 777 as this is IN that ZIP.

unfortunally, the sentance from the changelog "Default permissions for newly uploaded files and created directories using filemanager now rely on umask" will never occur on standard or default created ZIP archives as these ZIP's really DO have permissions inside which are used, and the 'umask' is not used.

the 'umask' most probably will not be a solution, because as an 'admin' using a 'user' acount, the 'umask' will be of 'admin or reseller' or maybe even 'root', and not the 'umask' of the 'user'. so, even with a usable umask, i still cant 'act' as user and will get permissions i dont want.
At this moment, as an admin or reseller, you better not use the filemanager 'extract' for ZIP for your users, or at least be very, very carefull.

we need the 'fm_xxxx' or similar solution to explicit set permissions from (ZIP) archives.

im not familiar with your 'drag & drop' issue, but hopefully it will be solved soon!

kind regards,

Arjan
 
Last edited:
cant find select php version.. using lastest version of directadmin, openlitespeed did i missing something?
 
Thanks for the feedback @AngryDragon70. We have updated the zip extract operation, to use the default new file and new directory permissions when extracting files created by the systems that does not support UNIX permissions system (Windows OS). If the zip archive is created on the system which supports storing accurate permissions for files and directories then permissions stored in the zip archive will be used for extracted files.

This means extracting a zip file created on Windows system will create files with 0644 and directories with 0755 permissions.
 
We are unable to reproduce the logo problem. Please open a support ticket.
 
Oke will do. Just discovered only on 1 server it's working and when select to open the image on a new page then it's pointing at hostname like this:

Now if I log in and use that link on the non working servers, the header.gif is shown, so that works.

But from the user account it's only showing that IMG_SKIN_HEADER wich seems not to redirect to the header.gif image.
I'll open a ticket then. Unless this rings a bell.
We didn't change anything on the servers skinwise, just update normally.
 
You must log in or register to reply here.
Back
Top